System, method, and computer program product for executing scripts on mobile devices

ABSTRACT

Described herein are systems, methods, computer program products, and combinations and sub-combinations thereof, for executing scripts that can be loaded on mobile devices (as well as other types of devices), and for users of mobile devices to interact with such scripts on their devices in an interactive manner. According to embodiments, the present invention performs script operations for mobile devices including steps for sending a request for an object and a list of support languages, and receiving the object and any related scripts in the supported languages.

BACKGROUND OF THE INVENTION

[0001] 1. Field of the Invention

[0002] The present invention relates generally to mobile communications,and more particularly relates to technology for using interactiveapplications while on-line and off-line on mobile devices.

[0003] 2. Related Art

[0004] A variety of mobile devices (such as personal data assistants, orPDAs) exist. Such mobile devices include ones based on the Palmoperating environment and the Windows CE operating environment.

[0005] A variety of software applications for those mobile devices alsoexist.

[0006] What does not exist prior to the invention are softwareapplications for enabling web content (as well as other objects) to beloaded on mobile devices, and for users of mobile devices to operatewith such web content on their mobile devices in an interactive mannerwhile in an off-line mode.

SUMMARY OF THE INVENTION

[0007] Briefly stated, the invention includes systems, methods, computerprogram products, and combinations and sub-combinations thereof forenabling web content (as well as other objects) to be loaded on mobiledevices (as well as other types of devices), and for users of mobiledevices to operate with such web content on their mobile devices in aninteractive manner while in an off-line mode.

[0008] According to embodiments, the present invention performs scriptoperations for mobile devices including steps for sending a request foran object and a list of support languages, and receiving the object andany related scripts in the supported languages.

[0009] These and additional features and advantages of the presentinvention will become more apparent from the detailed description setforth below when taken in conjunction with the drawings in which likereference characters generally identify corresponding elementsthroughout.

BRIEF DESCRIPTION OF THE FIGURES

[0010] The accompanying drawings, which are incorporated herein and formpart of the specification, illustrate embodiments of the presentinvention and, together with the description, further serve to explainthe principles of embodiments of the invention.

[0011]FIG. 1A is a block diagram of an embodiment of the invention;

[0012]FIG. 1B is an alternative block diagram of the invention;

[0013]FIG. 1B1 is a block diagram of an example data processing unituseful in some embodiments for implementing items from FIGS. 1A and 1B;

[0014]FIGS. 1C, 1D, 1E, 1F, 1G, 1H, 1I, and 1J are used to generallydescribe embodiments of the invention;

[0015]FIG. 2A is a block diagram illustrating additional modulesaccording to an embodiment of the invention;

[0016]FIG. 2B1 is a block diagram illustrating an additional moduleaccording to an embodiment of the invention;

[0017]FIG. 2B2 is a block diagram illustrating an additional moduleaccording to an embodiment of the invention;

[0018]FIG. 2C is a diagram illustrating some processing componentsaccording to an embodiment of the invention;

[0019]FIG. 2D1 is an example flowchart relating to structuringinteractive content according to an embodiment of the invention;

[0020]FIG. 2D2 is an example flowchart relating to structuring andrendering interactive content according to another embodiment of theinvention;

[0021]FIG. 2E is a diagram illustrating an example of content formattingaccording to an embodiment of the invention;

[0022]FIG. 2F1 is a diagram illustrating the content instantiationarchitecture according to an embodiment of the invention;

[0023]FIG. 2F2 is a diagram illustrating the content instantiationarchitecture according to another embodiment of the invention;

[0024]FIG. 2F3 is a flowchart relating to a optimized data modificationaccording to an embodiment of the invention;

[0025]FIG. 2G is a diagram illustrating an example of a databasearchitecture;

[0026]FIG. 2H is a diagram illustrating the content structure accordingto an embodiment of the invention;

[0027] FIGS. 2I1 and 2I2 demonstrate CSS style examples according toembodiments of the invention;

[0028]FIG. 2J demonstrates an example of floating images, where the textflows around the image;

[0029]FIG. 2K is an example architecture showing construction, layout,rendering, and cross-platform technology, according to embodiments ofthe invention;

[0030]FIG. 2L is an example operation where a device is able to syncwith a current server, according to embodiments of the invention;

[0031]FIG. 3A is an example flowchart relating to a server cache fortransformed content according to an embodiment of the invention;

[0032]FIG. 3B is an example flowchart relating to a server cache fortransformed content having negative caching according to an embodimentof the invention;

[0033]FIG. 3C is an exemplary fetch diagram illustrating hits on aserver occurring at the same time;

[0034]FIG. 3D is an example flow diagram representing a method forrandomizing the expiration of objects set to expire at the same timeaccording to an embodiment of the invention;

[0035]FIG. 3E is a diagram showing freshness lifetime for an objectaccording to an embodiment of the present invention;

[0036]FIG. 3F is a block diagram illustrating a single account/profilehaving multiple devices according to an embodiment of the invention;

[0037]FIG. 3G shows an example screen shot for enabling a user to addmultiple servers according to an embodiment of the invention;

[0038]FIG. 3H is an exemplary block diagram representing a single mobiledevice that connects to multiple servers according to an embodiment ofthe invention;

[0039]FIG. 3I is an exemplary flow diagram representing a sync processfor a device connected to multiple servers according to an embodiment ofthe invention;

[0040]FIG. 3J is an exemplary diagram illustrating a multipledevice—multiple server configuration according to an embodiment of theinvention;

[0041]FIG. 4 is a block diagram illustrating script compiler modulesaccording to an embodiment of the invention;

[0042]FIG. 5 is a block diagram illustrating a language interpretermodule according to an embodiment of the invention;

[0043]FIG. 6 is a block diagram illustrating the operations of delegatedlanguage interpreter modules according to an embodiment of theinvention;

[0044]FIG. 7 is a block diagram illustrating a server with a server-sidelanguage interpreter module according to an embodiment of the invention;

[0045]FIG. 8 is a flowchart showing a routine for script operationsaccording to an embodiment of the invention;

[0046]FIG. 9 is a flowchart showing a routine for executing scriptsaccording to an embodiment of the invention;

[0047]FIG. 10 is a flowchart showing a routine for updating propertiesaccording to an embodiment of the invention; and

[0048]FIG. 11 is a flowchart showing a routine for server-side scriptoperations according to an embodiment of the invention.

[0049] It should be understood that these figures depict embodiments ofthe invention. Variations of these embodiments will be apparent topersons skilled in the relevant art(s) based on the teachings containedherein. For example, the flow charts contained in these figures depictparticular operational flows. However, the functions and steps containedin these flow charts can be performed in other sequences, as will beapparent to persons skilled in the relevant art(s) based on theteachings contained herein.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0050] 1. Overview of Embodiments of the Present Invention

[0051] Embodiments of the present invention are briefly described inthis section.

[0052] Briefly stated, the invention is directed to placing objects suchas, but not limited to, Internet or Web content on data processingdevices, such as but not limited to mobile devices. Table 1 listsexamples of such Internet content, although the invention is not limitedto these examples. TABLE 1 Internet Content Internet content includesbut is not limited to: HTML JavaScript ™ Channels Java ™ ActiveXMultimedia: Images (e.g., JPEG, GIF, PNG, vector graphics, etc.) AudioFiles (e.g. MP3) Video (e.g. AVI) Streaming Content: Voice/Data/VideoBinary files XML Applications Data Objects Documents Anything that canbe delivered via a “browser”

[0053] Table 2 lists examples of mobile devices, although the inventionis not limited to these examples. TABLE 2 Mobile Devices Mobile devicesinclude but are not limited to: Handheld Computers Cellular PhonesInternet-enabled Phones Pagers Radios TVs Audio Devices Car AudioSystems Recorders Text-to-Speech Devices Bar-code Scanners NetAppliances Mini-browsers Personal Data Assistants (PDAs)

[0054]FIG. 1C illustrates the concept of the invention of placingobjects on data processing devices, such as mobile devices.

[0055] 1.1 Enabling Mobile Devices to Interact with NetworkedApplications

[0056] The invention includes technology for using applications onmobile devices that interact with the Internet or with intranets. Theinvention enables applications available via a network or via anInternet/intranet to download and to run on mobile devices.Consequently, the invention includes software and methods foradministering a server that manages the variables relevant to a mobiledevice/server environment.

[0057] The invention enables:

[0058] Mobile devices to operate in conjunction with a Web server, evenwhen the mobile devices are not coupled directly to the PC usingportable on-device servers: Web pages are loaded, viewed, cached, anddeleted even when the device is not coupled to any network.

[0059] Mobile devices to operate in conjunction with the Web, Internet,or intranet via a connection mechanism and then in disconnected mode orwith the Web, Internet, or intranet in wireless mode with a continuousor a discontinuous connection mechanism.

[0060] A technique for interactive connectivity between handheldcomputers and computer networks.

[0061] Fleet management for centrally administering information in ahandheld network environment that includes, but is not limited to, userdata, user groups, group channels, channel data, personal channels,commercial channels, user accounts, corporate account, softwaregroupings, personal information management, form delivery, formmanagement, device configuration, device databases, device contents, anddevices parameters.

[0062] Obtaining updated Web pages and other network objects, for usewhen the mobile device is not communicating with the PC.

[0063] An example mobile device/server environment is shown in FIG. 1D.

[0064] 1.2. Rapid Transfer of Web Pages to Mobile Devices

[0065] To improve efficiency of data exchange between mobile devices andnetworked content, the invention includes an improved communicationprotocol that collects requests and responses for network objects into asmaller number of protocol (such as HTTP) requests and responses. Theserver also determines the nature and the resources of the mobiledevice. This protocol is represented, for example, in FIG. 1E.

[0066] Downstream, the data is encoded in a data format called contentstream (tokenized version of the data) and sent to the device. Thecontent stream format creates a tokenized codification of HTML pagesthat is sent to the device. (The device receives the content stream andpresents the material on the device.)

[0067] The HTML page is encoded into the content stream and sent to thedevice. The encoding is a mapping of parent and child HTML elementsand/or resources to alphanumeric values.

[0068] The sync operation of the invention includes varioussynchronization processes that can collect information from the Internetto a server, and to the client. In embodiments, the usage of the term“sync” refers to the overall operation of connecting a client to aserver for the exchange, interaction, creation, and removal of data.

[0069] In one embodiment, syncing can be defined as mirroring data on aclient and a server, such that the data is the same on client andserver. In other embodiments, syncing can be defined as overwriting dataon a client or on a server, such that the data on either a clientreplaces the data on a server, and vice versa.

[0070] In one embodiment, a sync operation involves a user placing amobile device into an adapter that includes a sync button. The adapteris connected to a server. Upon pressing the sync button, the userinitiates the sync operations of the present invention, which includevarious synchronization processes (specific delivery modes). Thus, theterm sync is meant to refer to the overall operation of linking a clientto a server. Synchronization is meant to refer to the specific processof copying, adding, filtering, removing, updating and merging theinformation between a client and a server. Any number of synchronizationprocesses can be executed during a sync.

[0071] Before being sent downstream the data is compared to the datathat is known to be on the client and then the client is updated all atonce in a one-up/one-down synchronization method, which is representedin FIG. 1F. The server sets the client to preemptively prepare alldevice information necessary during the sync. Then the server receivesthe set of information in a one-up fashion. The server collates theinformation and sends the information in a one-down fashion. Thisoptimizes the sync's efficiency and speed. The sync process, accordingto embodiments of the invention, is represented in FIGS. 1G and 1H.

[0072] 1.3. Optimizing Content of Web Pages for Mobile Devices

[0073] When Web content and other network objects pass through theserver they are processed to minimize their size and to optimize theirdelivery to mobile devices: for presentation, for ease of use, forefficiency, for size, etc.

[0074] The invention uses server logic to optimize content. The serverassesses the mobile device to optimize web content for the particulardevice. Factors that the server logic considers when performing thisoptimization include, but are not limited to (it is noted that theserver may consider subsets of the following, depending on theapplication and implementation):

[0075] Dynamic memory specifications

[0076] High memory specifications

[0077] Protected Memory

[0078] Storage Memory

[0079] Database Memory

[0080] Available storage space

[0081] Screen size

[0082] User profile(s)

[0083] Color depth

[0084] Applications on device

[0085] Buttons on-device

[0086] Data markers (e.g., cookies, tokens)

[0087] Preferences

[0088] Fonts

[0089] Font specifications

[0090] Sync type

[0091] Synchronization types

[0092] Supported data types

[0093] Supported mime types

[0094] Connection/Network profile

[0095] An example optimization process is shown in FIG. 11.

[0096] On the server, the graphic is optimized per the state informationof the device. If the device sends down the need for the graphic on apage for a device with a display that is 27 cm wide and in grayscale,the server sends its best version of a graphic optimized for thatenvironment.

[0097] The technology of the invention is extended by tags on HTML pagesthat identify content that is designed for additional modifications. Anyand all bytes processed by the server are potentially examined forcompression/optimization. The server detects the tag and executes thenecessary logic.

[0098] Table 3 illustrates example tags (the invention is not limited tothe tags shown in Table 3). TABLE 3 Sample Markup Language Tag Effect<META NAME=“Handheld- This tag enables several HTML features Friendly”content=“True”> that are normally turned off. Most notably, Theinvention does not try to display TABLE tags or the HSPACE and VSPACEattributes of IMG tags unless the page is marked as “HandheldFriendly”.Most TABLEs or H/VSPACEs are designed for much larger screens.<AGIGNORE></ Used in a wireless channel. Use the AGIGNORE> AGIGNORE tagto surround content within an HTML page that may be inappropriate orunattractive on Internet- enabled phones. <AGPAGEBREAK Used in awireless channel. Breaks up TITLE=”your title> pages on request. Whenprocessing pages for devices other than WAP phones, the server ignoresthe AGPAGEBREAK tag.

[0099] Web Content Aggregation, Web Channel Development, and Web ContentDelivery for Users of the Internet and of Mobile Devices

[0100] The invention is extended by the coupling of devices to thecontent available at the server web site (see the example shown in FIG.1J).

[0101] These and other embodiments of the present invention aredescribed in greater detail below.

[0102] Structural Embodiments of the Present Invention

[0103]FIG. 1A is a block diagram of a data processing environment 102according to an embodiment of the invention. The data processingenvironment 102 includes a server 104 (although only one server 104 isshown, in practice the data processing environment 102 may include aplurality of servers), one or more devices 106, one or more adapters118, and one or more providers 128.

[0104] Generally, the server 104 maintains a collection of channels. Inan embodiment, a channel comprises a collection of objects. An object isany entity that can be transferred to a client 108, such as but notlimited to content, applications, services, images, movies, music,links, etc.

[0105] A channel includes a number of properties. At least some of theseproperties define the objects that the channel includes. Such propertiesinclude, but are not limited to, the following (properties of channelsmay vary depending on the application and/or implementation):

[0106] A name of the channel.

[0107] A location of a root object (such as but not limited to a URL).In an embodiment, this root object is included in the channel. Anindication of the number of levels below the root object, for which toinclude objects in the channel. For example, in an embodiment, if thisproperty is equal to “1 level,” then all objects that are 1 level downfrom the root object (reached by traversing links in the root object),are included in the channel. If this property is equal to “2 levels,”then all objects that are 1 level down from the root object (reached bytraversing links in the root object), and all objects that are 1 leveldown from those objects (reached by traversing links in those objects),are included in the channel. Embodiments of the invention allow “uneven”trees, where some branches of the tree extent to a greater number oflevels than other branches of the tree. In other embodiments, the treesare even or balanced.

[0108] A maximum size of the channel. For example, if this is set to 500Kbytes, then the aggregate size of the objects in the channel cannot begreater than 500 Kbytes. If the aggregate size of the objects in thechannel is greater than this value, then embodiments of the inventionmay delete objects from the channel and/or delete portions of objects inthe channel.

[0109] An indication of which resource objects are enabled for thechannel:

[0110] An indication of whether or not images are to be included in orexcluded from objects in the channel; and

[0111] An indication of whether or not scripts are enabled in objects inthe channel.

[0112] A refresh methodology.

[0113] It is noted that the properties associated with channels may varyfrom implementation to implementation. Also, implementations may employcombinations of the above properties, and/or properties in addition tothe following, as will be appreciated by persons skilled in the relevantart(s).

[0114] The invention includes processes for managing channels, includingbut not limited to adding channels to the collection of channelsmaintained by the server 104.

[0115] The server 104 offers channels to clients 108. A user associatedwith or on behalf of a client 108 may access the server 104 and view thecollection of channels. The client 108 (via the user, for example) maythen select any combination of the channels in the collection. Theserver 104 maintains a list of the channels associated with each of theclients 108.

[0116] During a synchronization process, the server 104 loads a device108 with the channels associated with the client 108. Generally, theserver 104 does this by obtaining from providers 128 the objects definedby the channels, and causing those objects to be stored on the client108. Thus, during the synchronization process, the server 104 will loadthe client 108 with the selected channels. More particularly, the server104 will load the client 108 with the objects associated with thechannels.

[0117] The client 108 may process and use those objects when notconnected to the server 104. The invention enables the client 108 toactively interact with the objects and channels.

[0118] In one embodiment, the client 108A directly interacts with theserver 104 via some transmission medium 120B, which may be any wired orwireless medium using any communication protocol.

[0119] In another embodiment, the client 108B indirectly interacts withthe server 104 via an adapter 118. For example, the client 108B may be amobile device (such as a Palm device) and the adapter 118 may be acradle and a computer coupled to the cradle (the mobile device isinserted into the cradle). In this instance, the adapter 118 presentsitself to the server 104 as a client 108B (via client communicationsmodule 110C). When the server 104 sends objects to the adapter 118, theadapter interface module 116 writes those objects to client 108B. Inembodiments, adapter interface module 116 can be a Hot Sync™ Manager, anActive Sync™, etc. It is noted that the invention is not limited to anyof the implementation examples discussed herein.

[0120] The components shown in FIG. 1A shall now be described in greaterdetail.

[0121] The server 104 includes an administration module 122, a databasemodule 126, a user interface 130, a web synchronization module 124, aserver extension module 156, a fleet management module 154, anotification module 132, and a server communication module 114. Otherembodiments of server 104 may include a subset of these modules, and/ormay include additional modules.

[0122] The administration module 122 controls and manages the states ofthe server 104 and the clients 108. For example, the administrationmodule 122 manages and controls groups of clients 108, permissionsassigned to clients 108, groups, and channels. For example, theadministration module 122 administers the users/clients 108 assigned togroups, and the channels associated with users. These and additionalfunctions performed by the administration module 122 are describedherein.

[0123] The database module 126 controls access to databases associatedwith the server 104. The database module 126 maintains informationrelevant to the clients 108, as well as information relevant to themodules contained in the server 104. The database module 126 managesinformation on the collection of channels maintained by server 104.These and additional functions performed by the database module 126 aredescribed herein.

[0124] The user interface 130 is, in an embodiment, a graphical userinterface (GUI) that enables users and clients 108 to access functionsand modules offered by the server 104. More generally, the userinterface 130 within server 104 provides access to server 104 and themodules and resources contained therein.

[0125] The invention supports various server web sites that areavailable through any communication medium, such as but not limited tothe Internet, intranets, direct dial up links, etc. The UI 130 enablessuch web sites.

[0126] These and additional functions performed by the user interface130 are described herein.

[0127] The web synchronization module 124 is an application/instance ofserver extension module 156, and controls synchronization of web contentto client 108. The invention may include other synchronization modules(which are application/instances of server extension module 156) thatcontrol synchronization of other types of objects to clients 108. Forexample, the server 104 may administer a calendar that may be installedon clients 108. The synchronization of appointments, events and/or dateson this calendar between clients 108 and the server 104 may be performedby a calendar synchronization module. These and additional functionsperformed by the server extension module 156 are described herein.

[0128] The fleet management module 154 performs functions associatedwith fleets of clients 108, which are groups of clients 108. Forexample, fleet management module 154 may perform global or massoperations on groups (fleets) of clients 108, such as loading orupdating an application on groups (fleets) of clients 108. Anotherexample of a mass operation is retrieval of information on clients 108in a fleet, such as the free memory in clients 108 in a fleet (thiswould help an organization determine if its clients 108 need a memoryupgrade). These and additional functions performed by the fleetmanagement module 154 are described herein.

[0129] The server extension interface/module 156 enables modules, suchas third party modules, to operate in or work with the server 104 (andmodules contained in the server 104). The server extension module 156presents an API (application programming interface). Modules in theserver 104 may operate with other devices in the server 104 byconforming to the server API.

[0130] For example, the web synchronization module 124 and the fleetmanagement module 154 (as well as other types of synchronizationmodules, not shown in FIG. 1A) may interact with databases on the server104 via the database module 126 by going through the server extensionmodule 156. The web synchronization module 124 and the fleet managementmodule 154 may not be able to interact directly with the database module126 for a number of reasons. For example, they may support differentdata formats or simply “speak different languages.” However, they caninteract via the server extension module 156 as well as other servermodules as long as they conform to the API of the server extensionmodule 156. This is true of any modules in the server 104, or thatinteract with the server 104.

[0131] Server communication module 114 enables communication between theserver 104 and entities external to the server 104, such as clients 108,adapters 118, providers 128, work stations, etc. The server 104communicates with these entities via communication mediums 120, whichmay be any type of wireless or wired communication using any protocol.It is noted that multiple server communication modules 114 may executein a single server 104. For example, in one embodiment, servercommunication module 114 is a TCP/IP stack. In another embodiment,server communication module 114 is a secure socket layer stack or acompression stack. The invention is not limited to any implementationexamples discussed herein. These and additional functions performed bythe server communication module 114 are described herein.

[0132] The notification module 132 sends objects to clients 108 beyondobjects related to channels associated with clients 108. Such objectscould be requested by client 108 in advance. For example, a client 108could ask for a notification when an event happens, such as when a stockreaches a target price. When the event occurs, the notification module132 would cause an appropriate notification(s)/object(s) to be sent tothe client 108. Alternatively, the notification module 132 may sendobjects to clients 108 without any prior explicit request from theclient 108. For example, the notification module 132 might send channelsto clients 108 when such channels are identified to be similar to thosealready selected by the clients 108. Also, the notification module 132might send appropriate notifications/objects to the clients 108 whensuch clients 108 receive email or faxes at the server 104. Inembodiments, the notification module 132 transmits such objects to theclient 108 immediately when the event occurs, during the nextsynchronization with the client 108, or at some other futuresynchronization.

[0133] An alternative representation of server 104 is shown in FIG. 1B.FIG. 1B illustrates, for example, that messages from entities outside ofserver 104 are received by server extension interface/module 156 viaserver communications modules 114. Generally, such messages representrequests for the server 104 to perform various functions. The serverextension module 156 conceptually operates as a dispatcher who routessuch messages to other modules contained in the server 104, such as websynchronization module 124 (who handles requests to synchronize with webcontent), notification module 132, fleet management module 154 (whohandles fleet related requests), and/or third party modules 155 (such asother synchronization modules). Thus, the invention supports modules 155generated by third parties to perform various functions. Such modules155 “plug-in” to the server 104 via the server extension module 156.

[0134] Referring again to FIG. 1A, the devices 106 may be any type ofdata processing device. In embodiments of the invention, the devices 106are mobile computing devices, although the invention is not limited tothese embodiments. In such example embodiments, the devices 106 mayinclude, but are not limited to, handheld computers, cellular phones,internet-enabled phones, pagers, radios, tvs, audio devices, car audiosystems, recorders, text-to-speech devices, bar-code scanners, netappliances, mini-browsers, personal data assistants (PDAs), etc.

[0135] In embodiments of the invention, the devices 106 includesoftware, hardware, and/or combinations thereof related to clientfunctionality (such client functionality is described herein). When adevice 106 includes such software, hardware, and/or combinationsthereof, the device 106 is referred to herein as a client 108.Accordingly, it can be said that the data processing environment 102includes one or more clients 108.

[0136] Clients 108 each may include a layout and rendering module 134, aforms module 136, a control module 142, a user interface 144, a clientextension interface 138, a client interface module 112, a clientcommunications module 110, a JavaScript™ engine 140, and a databasemodule 146. Other embodiments of clients 108 may include a subset ofthese modules, and/or may include additional modules.

[0137] Layout and rendering module 134 controls the processing of dataobjects on client 108, such as the layout and rendering of data objectson client 108. For example, the layout portion of module 134 obtainsinformation from databases of the client 108 (via the database manager146) and determines where such information should be rendered on thedisplay of the client 108. Such information may include anything thatcan be rendered, such as but not limited to images, text, links, etc.The rendering portion of module 134 is responsible for drawing items onthe display (drawing bits to the screen). These and additional functionsperformed by the layout and rendering module 134 are described herein.

[0138] The forms module 136 controls and manages forms. For example, inembodiments the forms module 136 manages aspects of off-line forms, suchas HTML forms and/or multi-page forms. The forms module 136 enablesaccess to and user interaction with forms (in some embodiments, theforms module 136 via UI 144 enables users of client 108 to directlyaccess forms). The forms module 136 maintains the status of forms. Formsmodule 136 can also include a forms manager (not shown) to provide addedfunctionality. These and additional functions performed by the formsmodule 136 are described herein.

[0139] The user interface 144 is preferably a graphical user interfacethat enables users to interact with client 108 and functions and modulesprovided by the client 108. More generally, UI 144 controls howfunctions presented by modules of the client 108 are presented to users.The UI 144 controls how users interact with such functions and modules.It is noted that the functionality of the UI 144 may be distributed. Forexample, portions of the UI 144 may reside in the forms module 136, aswell as other modules of client 108. These and additional functionsperformed by the user interface 144 are described herein.

[0140] The client extension interface 138 enables modules, such as thirdparty modules, to operate in or work with the client 108 (and modulescontained in the client 108). The client extension interface 138, alsoknown as an on-device server, presents an API (application programminginterface) that is, in embodiments, common to clients 108 on manyarchitectures.

[0141] Modules in the client 108 can work together via the clientextension interface 138. For example, the JavaScript™ engine 140 maydecide that it wishes to display a message to the user. To do this, theJavaScript™ engine 140 would work through the client extension interface138 to cause the UI 144 to display the message to the user. TheJavaScript™ engine 140 may not know how to directly interact with the UI144. However, as long as both the JavaScript™ engine 140 and the UI 144conform to the API of the client extension interface 138, then they canoperate together.

[0142] Similarly, the control module 142 may decide that it needs tostore some data in a database. The control module 142 would do this byworking with the client extension interface 138 to access the databasemodule 146 to effect such a modification to the databases in the client108. These and additional functions performed by the client extensioninterface 138 are described herein.

[0143] The JavaScript™ engine 140 executes objects written in theJavaScript™ language that operate on client 108. As noted, theJavaScript™ engine 140 conforms to the API of the client extensioninterface 138, and works with the client extension interface 138 to workwith other modules in client 108. These and additional functionsperformed by the JavaScript™ engine 140 are described herein.

[0144] Although not shown in FIG. 1A, embodiments of the inventioninclude other engines for executing other types of scripts on client108. These other engines can interact with other modules on client 108as long as the engines conform to the API of the client extensioninterface 138.

[0145] The database module 146 controls access to databases associatedwith client 108. More generally, the database manager 146 controlsaccess to resources on the client 108. For example, the control module142 may interact with the database manager 146 to open an address bookin the databases, and to write a record to the address book.Alternatively, the forms module 136 can interact with the databasemodule 146 to access forms that are stored in the databases. These andadditional functions performed by the database module 146 are describedherein.

[0146] Client communications module 110 enables the client 108 tointeract with external entities, such as server 104. In embodiments, theclient communications module 110 enables TCP/IP traffic, although theinvention is not limited to this example. More generally, the clientcommunications module 110 enables communication over any type ofcommunication medium 120, such as wireless, wired, etc., using anycommunication protocol, such as a pager protocol. These and additionalfunctions performed by the client communications module 110 aredescribed herein. The client interface module 112 enables the client 108to communicate with adapters 118. Client interface module 112 optionallylinks to client communications module 110 in some embodiments to providefunctionality (for example, when the client communications module 110uses a wireless modem's drivers, which are accessed via client interfacemodule 112). In embodiments, the client interface module 112 may be HotSync™ Manager in the Palm operating environment, or Active Sync™ in theWindows CE™ operating environment, or Pilot Link™ in the Unix operatingenvironment. It is noted that these implementation examples are providedfor illustrative purposes only. The invention is not limited to theseexamples. These and additional functions performed by the clientinterface module 112 are described herein.

[0147] The control module 142 coordinates the activities of the othermodules in client 108 so that all the modules share resources properly.For instance, control module 142 can determine priorities for sharedresources such as processing time, accessing memory, etc.

[0148] Providers 128 are sources of various types of objects, such asbut not limited to content (content providers 128A), applications(application providers 128B), services (service providers 128C), etc.Providers 128 may also include servers 104′ (similar to server 104),which may provide objects such as but not limited to content,applications, services, etc. For example, and without limitation, theapplication providers 128B may provide objects relating to (withoutlimitation) operating system updates/changes, system upgrades,application updates/changes, etc.

[0149] Adapters 118 include an adapter interface module 116, a userinterface 148, a database module 150, an adapter synchronization module152, and a client communications module 110. Other embodiments ofadapters 118 may include a subset of these modules, and/or may includeadditional modules.

[0150] Client communications module 110 is the same as similarly namedmodules in clients 108.

[0151] The adapter interface module 116 enables the adapter 118 tocommunicate with clients 108.

[0152] The adapter synchronization module 152 is involved withsynchronization operations between server 104 and clients 108.

[0153] The UI 148 enables users to interact with modules and functionsof adapter 118.

[0154] The database module 150 controls access to databases associatedwith adapter 118. The database module 150 manages information needed forclients 108 to remain in sync with server 104. In some embodiments, theadapter 118 does not include the database module 150 or the UI 148(i.e., in embodiments where the adapter 118 operates essentially as apipe, as in some embodiments on Unix).

[0155] These and additional functions performed by modules of theadapter 118 are described herein.

[0156] Additional modules and features of embodiments of the inventionare described below.

[0157] 1.4 Example Implementation Embodiments

[0158]FIG. 1B1 illustrates a block diagram of a data processing unit103A that can be used to implement the entities shown in FIGS. 1A and1B. It is noted that the entities shown in FIGS. 1A and 1B may beimplemented using any number of data processing units 103A, and theconfiguration actually used is implementation specific.

[0159] Data processing unit 103A may represent laptop computers, handheld computers, lap top computers, and/or any other type of dataprocessing devices. Which type of data processing device used toimplement entities shown in FIGS. 1A and 1B is implementation specific.

[0160] Data processing unit 103A includes a communication medium 103B(such as a bus, for example) to which other modules are attached.

[0161] Data processing unit 103A includes one or more processor(s) 103C,and a main memory 103D. Main memory 103D may be RAM, ROM, or any othermemory type, or combinations thereof.

[0162] Data processing unit 103A may include secondary storage devices103E, such as but not limited to hard drives 103F or computer programproduct interfaces 103G. Computer program product interfaces 103G aredevices that access objects (such as information and/or software) storedin computer program products 103. Examples of computer program productinterfaces 103G include, but are not limited to, floppy drives, ZIP™drives, JAZ™ drives, optical storage devices, etc. Examples of computerprogram products 103H include, but are not limited to, floppy disks,ZIP™ and JAZ™ disks, memory sticks, memory cards, or any other medium onwhich objects may be stored.

[0163] The computer program products 103H include computer useablemediums in which objects may be stored, such as but not limited tooptical mediums, magnetic mediums, etc.

[0164] Control logic or software may be stored in main memory 103D,secondary storage device(s) 103E, and/or computer program products 103H.

[0165] More generally, the term “computer program product” refers to anydevice in which control logic (software) is stored, so in this context acomputer program product could be any memory device having control logicstored therein. The invention is directed to computer program productshaving stored therein software that enables a computer/processor toperform functions of the invention as described herein.

[0166] The data processing unit 103A may also include an interface 103Jwhich may receive objects (such as data, applications, software, images,etc.) from external entities 103N via any communication mediumsincluding wired and wireless communication mediums. In such cases, theobjects 103L are transported between external entities 103N andinterface 103J via signals 103K, 103M. In other words, such signals103K, 103M include or represent control logic for enabling a processoror computer to perform functions of the invention. According toembodiments of the invention, such signals 103K, 103M are alsoconsidered to be computer program products, and the invention isdirected to such computer program products.

[0167] 2. A Cross-Platform Browser and Cleint/Server Software Innovationfor Mobile Devices

[0168] As described above, the technology uses a cross-platform strategyfor serving and obtaining content requests on and across platforms andprocessors available to mobile devices. In some embodiments, the clientenables desktop personal computer (PC) functionality on mobile devices.For example, the client can support dynamic hypertext mark-up language(DHTML) on mobile devices; it can support device-side interpretation ofJavaScript™; and it can provide secure client/secure protocol/secureserver interaction. It is noted that these examples are mentioned forillustrative purposes only, and are not limiting. Addition functions andcapabilities are within the scope and spirit of the present invention,as will be appreciated by persons skilled in the relevant art(s) basedon the teachings contained herein.

[0169] Additionally, the client 108 of the invention enables per channel(and/or per page) username and password authentication for transactions(e.g. in e-commerce applications and/or channels), digital notarization,content hold and deliver technology in connected and disconnected modes,and bookmarks. Furthermore, the clients 108 (i.e., client 108A and 108B)of the invention enable support for multiple protocols such as mailtoand dialto interfaces, and DHTML. It is noted that these examples arementioned for illustrative purposes only, and are not limiting. Theinvention is applicable to other protocols, as will be appreciated bypersons skilled in the relevant art(s) based on the teachings containedherein.

[0170] In an embodiment, the client 108 of the invention integrates withother mobile device applications through methods such as but not limitedto: cut and paste, domain integration of Find and/or Search methods, andmobile device communication between on-device applications and theirseparate tables of data. For example, the client 108 of the inventioncan invoke a vector graphics display or a word processor or spreadsheetfile synced to the device. In one embodiment, these features correspondand extend the functionality of pluggable MIME types on server 104.

[0171] In embodiments, the client 108 is designed to support theadditional Internet document standards: HTML 4.0, XHTML 1.0, CSS(Cascading Style Sheets), and the W3C DOM (Document Object Model). It isnoted that these examples are mentioned for illustrative purposes only,and are not limiting. The invention is applicable to other standards, aswill be appreciated by persons skilled in the relevant art(s) based onthe teachings contained herein.

[0172] Referring to FIG. 2A, a block diagram, illustrating additionalmodules according to an embodiment of the invention, is shown.

[0173] Server 104 can include parser module 201A, layout module 201B,and/or proxy rendering module 201C. Modules 201A-201C can be implementedin server 104 alone or in combination with other elements or modules,such as in combination with clients (such functionality can also beperformed completely by clients). It is noted that the functionalityassociated with modules may vary from implementation to implementation.The specific functionality and implementation described herein representan example embodiment of the invention. Other embodiments will beapparent to persons skilled in the relevant art(s) based on theteachings contained herein.

[0174] Also, implementations may employ combinations of the abovemodules, and/or employ the functionalities of the above modules assub-modules to other modules of server 104, as will be appreciated bypersons skilled in the relevant art(s).

[0175] In one embodiment, parser module 201A reads the objects on apage, such as a Web page. The parser module 201A separates out thedescription of each object on the page and generates a tree of objectsbased on their descriptions and the inherent relationship defined by thedescriptions. In one embodiment, the tree of objects is compatible withthe W3C DOM. Thus, in the case of HTML, the Web page is a description ofcontent objects using tags, attributes, and styles. In the case of WML,the page is a description of content object using binary data.

[0176] In one embodiment, layout module 201B maps the parsed objects ofa page and determines how the objects can be positioned and sized (orlaid out) in order to provide a page with similar substance on themobile device to which it is going to be transmitted. As with the otherembodiments of the layout module described herein, the layout module201B receives display, font color, and other device configurationinformation from the proxy render module 201C.

[0177] In a server-side layout embodiment, layout module 201B receivesthe display configuration of the mobile device from proxy render module201C. Proxy render module 201C provides server 104 with thefunctionality of layout and rendering module 134 (in this case, eitherof modules 134A or 134B) for any number of clients 108. In oneembodiment, the proxy render module 201C provides configurationinformation from a database, which stores previously obtainedconfiguration information. In embodiments described herein, the server104 receives the configuration information from the client 108. Forexample, server 104 receives the configuration information from layoutand rendering module 134. From this information, server 104 is able tooperate proxy render module 201C accordingly and provide data in theproper format. For example, in one embodiment, the proxy render module201C is able to produce byte code in the form of a content streamcompatible with the display hardware of device 106.

[0178] As such, proxy rendering module 201C determines the displaycapabilities of the device 106 to which the content stream is going tobe transmitted. Furthermore, in one embodiment, proxy rendering module201C determines information about how particular objects can appear(i.e., are positioned) on the display of a mobile device from deviceinformation stored in database module 126, rather than for a specificdevice 106 from information provided by client 108.

[0179] Furthermore, the functionality of these modules can beimplemented on clients 108. For example, the rendering functionality oflayout and rendering module 134 can provide the configurationinformation directly to the layout functionality of the same module. Inembodiments, modules implemented on the client 108 are designed tooperate on relatively small computers and/or mobile devices such asthose described herein as well as those similarly designed. Thecombination of functionalities in one module 134 is for illustrativepurposes. The combination may be separated and implemented in twoseparate modules as discussed with respect to server 104 above. Theseimplementations are discussed in more detail below.

[0180] Referring to FIG. 2B1, a block diagram, illustrating anadditional module according to an embodiment of the invention, is shown.

[0181] Client 108A can include client parser module 202A. Client parsermodule 202A provides functionality similar to parser module 201A asdescribed herein.

[0182] Referring to FIG. 2B2, a block diagram, illustrating additionalmodules according to an embodiment of the invention, is shown.

[0183] Client 108B can include client parser module 202B and clientinterface module 112B. Client parser module 202B provides functionalitysimilar to parser module 201A as described herein. Client interfacemodule 112B is capable of connecting with providers 128 viacommunication medium 120E. Providers 128, as described herein, arecontent providers, such as Web sites. Communications medium 120E may beimplemented to augment the connection with server 104 via adapter 118.For example, communications medium 120E, as shown, could connectdirectly to providers 128 via a wireless link in order to obtain updatedcontent from providers 128 or to transmit data to providers 128.

[0184] In one embodiment, the parsing functionality added to client 108via client parser modules 202A and 202B allows clients 108 to obtaincontent directly from providers 128 without server 104 transformation.Some embodiments of this distribution of functionality is discussedbelow with respect to FIG. 2C.

[0185] Referring to FIG. 2C, a diagram, illustrating some processingcomponents according to embodiments of the invention, is shown.

[0186] Content 203A from a page in the form of objects is parsed byparser module 203B, laid out by layout module 203C, rendered byrendering module 203D, and sent to mobile devices for display in theform of pixel data 203E. These objects can include but are not limitedto tags, attributes, and style information.

[0187] The modules 203B, 203C, and 203D are similar to the modulesdiscussed in FIGS. 2A, 2B1, and 2B2. FIG. 2C illustrates the feature ofthe invention where the method, system and computer program product canbe configured such that the operations of modules can be performed onserver 104 and/or clients 108, as well as on adapter 118 as well ascombinations thereof.

[0188] In the examples of FIG. 2C, the operational processes of each ofmodules 203B, 203C, and 203D are delineated by marker 203F for parsermodule 203B. Similarly, marker 203G delineates the operational processesof layout module 203C. Marker 203H shows the operational processes forrendering module 203D.

[0189] In embodiments of the invention, the operational processes ofthese modules, as well as the modules themselves, can be implemented oneither or both the server 104 or the client 108 (or adapter 118). Thisflexibility allows the invention to optimize the transformation anddelivery of content to mobile devices based on the capabilities of thedevices and/or requirements of users.

[0190] Line 203I illustrates an example implementation where modules203B and 203C are operating on server 104 to perform the functions ofparsing and layout. The asterisk of line 203I shows the transition toclient 108 (or adapter 118) and thus the operations of module 203D areperformed on client 108.

[0191] Similarly, lines 203J, 203K, and 203L illustrate other possibleapportioning of the operational tasks. The markers between the arrows oflines 203J, 203K, and 203L similarly showing the transition from one ofthe server 104 to client 108 (and/or adapter 118).

[0192] In additional embodiments, modules on both server 104 and client108 (and adapter 118) can operate in parallel or series on the objectsof content 203A.

[0193] Referring to FIG. 2D1, an example flowchart 204 relating tostructuring interactive content, according to an embodiment of theinvention, is shown.

[0194] In step 204A, server 104 receives a request for pages. In oneembodiment, the client 108 sends the request.

[0195] In step 204B, server 104 receives mobile device and clientinformation describing the capabilities of the client 108 and the device106. In one embodiment, client 108 sends information regarding thedisplay and memory specifications of the mobile device upon which it isoperating.

[0196] In step 204C, server 104 parses the pages into a mutable documentof content according to the device and client information of step 204B.In one embodiment, parser module 201A parses the pages into discreteobjects.

[0197] In step 204D, server 104 determines the rendering parameters ofthe client and mobile device according to the information obtained instep 204B. In one embodiment, proxy rendering module 201C provides therendering parameters of the client and mobile device.

[0198] In step 204E, server 104 lays out the document content accordingto the rendering parameters determined in step 204D. In one embodiment,the parsed objects of a page are assembled and formatted such that thepage displayed by the client on the mobile device has the samefunctional display or presentation as on any other device. In anembodiment, layout module 201B provides common layout services for theserver 104. Similarly, layout and rendering module 134A of FIG. 1Aprovides these services on client 108A.

[0199] In step 204F, server 104 determines the document table anddocument content to be sent to client 108 so that the client 108 can usethe content of the page(s). The structure and format of the documenttable and document content (according to embodiments) are discussedbelow.

[0200] In step 204G, server 104 compresses the document content,preferably on a discrete object-by-object basis (although otherembodiments are possible). For example, the discrete objects obtainedfrom the parsing of step 204C are compressed individually in step 204G.

[0201] In step 204H, server 104 encrypts the document content,preferably on a discrete object-by-object basis. For example, thediscrete objects obtained from the parsing of step 204C are encryptedindividually in step 204H.

[0202] In step 204I, server 104 serializes the document contentaccording to the discrete basis. For example, the document content isplaced in ordered blocks or sections. In one embodiment, the discretebasis may prioritize index or home pages and place them in places in theserialized chain of objects so that they may be readily recalled.

[0203] In step 204J, server 104 serializes the document attributesrelated to the document content according to the discrete basis. In oneembodiment, the document attributes are placed in a similar order as thedocument objects in step 204I. In another embodiment, the documentattributes are serialized based on the type of objects they respectivelyidentify.

[0204] In step 204K, server 104 transmits the serialized document toclient 108A and/or adapter 118 for delivery to client 108B. In oneembodiment, the serialized document is a content stream transmitted tothe device for client 108. The serialized document can provide anoptimized format for delivering content to mobile devices that may notbe designed to accommodate the relatively large file formats, which PCsare used to handling.

[0205] In the above description, server 104 is discussed as performingthe operations of flowcharts 204. This is just one embodiment of theinvention. Variations of this embodiment will be apparent to personsskilled in the relevant art(s) based on the teachings contained herein.For example, client 108 can perform some or all of the operations offlowchart 204, as discussed below.

[0206] Referring to FIG. 2D2, an example flowchart 204M relating tostructuring interactive content according to another embodiment of theinvention is shown.

[0207] In step 204N, client 108 (as discussed above, client 108 is usedto refer generically to client 108A and/or client 108B, unless statedotherwise) sends a request for pages.

[0208] In step 204Q, client 108 receives the requested pages. In oneembodiment, client 108B receives the pages directly from providers 128,as shown in FIG. 2B2. In another embodiment, client 108 receives therequested pages from the server 104.

[0209] In step 204R, client 108 parses the pages into a mutable documentof content. As described above, the mutable document allows for betteraccess and storage for the client.

[0210] In step 204S, client 108 determines the rendering parametersaccording to the local render module, such as layout and renderingmodule 134.

[0211] In step 204T, client 108 lays out the document of contentaccording to the rendering parameters determined by the local rendermodule, such as layout and rendering module 134. Such parametersinclude, for example, colors supported, device screen size, fontcharacteristics, etc.

[0212] In step 204U, client 108 displays the data on the screen. In oneembodiment, the render module of client 108 puts the pixel data on thescreen.

[0213] For example, the client communications module 110A receives thepages from server 104. Client parser module 202A parses the pages.Layout and rendering module 134A determines the rendering and layoutparameters and forwards the pixel data to the screen. Other examples andembodiments are discussed in detail below.

[0214] 2.1 Serialized Document Model

[0215] Similar to the PODS described herein, the document (data object)assembled through the steps of flowcharts 204 and 204M includes astructure that is advantageous for mobile devices. The document objectmodels (DOM) of an embodiment of the invention supports Copy-On-Writewhich is usually only implemented in hardware. This enables the creationof discretely compressed read-only documents (for example, thepre-processed content stream as described herein) that can be modifiedand saved and then loaded and modified incrementally on a discretebasis.

[0216] This embodiment allocates data in its final form. In anembodiment, read-only data in the content stream is, as best can beachieved, in its final, usable form. The data does not have to beduplicated for use as with other types of models. This aspect of theinvention is important given the relatively limited resources of mobiledevices.

[0217] 2.2 Memory Allocation

[0218] Furthermore, this model has a tight memory allocation scheme. Inan embodiment, memory is allocated in Pools and Arenas that are scopedto the lifetime of the object being allocated. For example, documentshave a memory scope. When an object whose lifetime is that of a documentis allocated, it is allocated from the owner document's memory scope.

[0219] When the document is destroyed, the associated memory scope canbe freed immediately. Objects that will exist for the life of a memoryscope will be allocated from the scope Arena (in an embodiment, arenaallocated objects cannot be individually freed). In an embodiment,objects whose lifetimes are more volatile will be allocated from thescope pool (where they can be later freed). This allocation is but anexample and others can be implemented depending on the device's memorystructure (and also possibly depending on other factors) as one skilledin the relevant art would recognize. As in the above example, when botharena and pool memory types exist, content can be stored in a read-only(arena) and/or in a writeable (pool). Further embodiments using thistype of memory allocation are discussed below.

[0220] Referring to FIG. 2E, a diagram illustrating an example ofcontent formatting according to an embodiment of the invention is shown.In this embodiment, an example button is shown within the document 205A.The button object includes a header 205B and the parameter informationstored as data 205C. Header 205B can include type information whichprovides a mechanism whereby there is a pointer or pointers to the typeof functions which operate on the data 205C.

[0221] Referring to FIG. 2G, a diagram illustrating an object modelrelated to those shown in FIGS. 2F1 and 2F2 is shown. FIG. 2G shows abutton object 207A that includes object pointers 207K. Object pointers207K comprise a vtable pointer 207B and a data object 207C. Vtablepointer 207B points to a vtable 207D that contains function pointers207F for accessing instance methods 207H.

[0222] Button object 207A and data 207C can be placed in writeablememory. Qualitative data can be read and written (thus, modified) byinstance methods 207H, which are designed to read and manipulate data207C.

[0223] There are drawbacks to this object model. They include, but arenot limited to:

[0224] 1) Data 207C is in writeable memory. Data 207C is relativelylarge. If data 207C is first available in read-only form, then it mustfirst be copied into writeable memory.

[0225] 2) Writeable memory is often scarce on mobile devices (as well asother devices).

[0226] 3) Data 207C cannot easily be maintained in compressed form asthe size of data 207C will change as it is modified. This requiresadditional writeable memory.

[0227] Additionally, the lack of a document table effectively means thatany changes to the data 207C or the type information in header 207Brequires a change to the vtable 207D which is used to operate on data207C. These changes have to be made globally so that the entire documentis recreated.

[0228] FIGS. 2F1 and 2F2 illustrate content instantiation architecturesaccording to embodiments of the invention.

[0229] Referring to FIG. 2F2, a diagram illustrating the contentinstantiation architecture according to an embodiment of the inventionis shown. FIG. 2F2 differs from FIG. 2G in that data 206K2 is separatedfrom object 206A. The addition of attribute pointer 206C, which pointsto data 206K2, serves as a link so that changes do not have to be madeglobally as in FIG. 2G.

[0230] Referring to FIG. 2F1, a diagram illustrating the contentinstantiation architecture according to an embodiment of the inventionis shown. FIG. 2F1 is differs from FIG. 2F2 in that data 206K can beread only and compressed. Instance methods 206H are designed to read thecompressed data.

[0231] The architectures of FIGS. 2F1 and 2F2 have advantages over thearchitecture of FIG. 2G. Unlike the architecture of FIG. 2G, data doesnot have to be decompressed or copied to writeable memory for initialuse. Data can be read, and/or displayed immediately. The architecturesof FIGS. 2F1 and 2F2 are very efficient for mobile devices (as well asother devices), which can have relatively limited memory or processingcapabilities, because they use compressed read-only data. Additionally,the architectures of FIGS. 2F1 and 2F2 are useful for applications wherememory and processing requirements need to be optimized, as well as forother applications as will be appreciated by persons skilled in therelevant art(s) based on the teachings contained herein.

[0232] Referring to FIG. 2F1, for example, document table 206A providestwo pointers: Vtable pointer 206B and attribute pointer 206C. Vtablepointer 206B points to a vtable 206D which includes header 206F andfunction pointers 206G. Header 206F includes information pertaining tothe class and type of functions being called. Function pointers 206Gincludes global, user, and low-level function pointers that provideaccess to the instance methods 206H of functions 206E.

[0233] Attribute pointer 206C points to the specific object in thecontent stream 206I similar to that discussed with respect to FIG. 2E.Header 206J and data 206K provide specific information about how toperform the functions pointed to in the vtable.

[0234] The use of document table 206A allows the entire document to beincrementally altered as may be required without having to totallyrestructure the document.

[0235] It is noted that the data 206K can be compressed. Content stream206I, header 206J, and data 206K can be in read-only memory. Instancemethods 206H can be designed to interpret the compressed data 206K sothat instance methods 206H can read, display and process data 206Kproperly.

[0236] According to embodiments of the invention, modifications to data206K are possible, but any modified data 206K objects are stored inwriteable memory. Attribute pointer 206C is updated to reflect themodification so that future use of the specific data 206K object isdirected to the modified object. The embodiments of FIGS. 2F1 and 2F2therefore provide for relatively less use of writeable memory on themobile device.

[0237] Software Modification on Write Method and Example

[0238] The embodiments of FIGS. 2F1 and 2F2 offer important advantagesto browsers. For example, mobile devices typically are designed aroundseveral different operating systems and/or hardware standards. The useof a client that enhances access helps to assure compatibility.Furthermore, the general features of mobile devices are relativelylimited compared to their PC counterparts. As such, mobile devicesbenefit from enhanced content storage, retrieval and modificationtechniques.

[0239] In an embodiment, data can be transformed as shown in FIGS. 2F1and 2F2. In an example embodiment, the objects 206A in FIG. 2F1 and 2F2share the same form, i.e., a compressed, read-only form. The read-onlyobjects 206A of FIG. 2F1 can be transformed by instance method 206H intothe writeable form shown in FIG. 2F2. In one embodiment, when instancemethod 206H is called, a software exception similar to a hardwareexception occurs.

[0240] Referring to FIG. 2F3, a flowchart 206P, relating to an enhanceddata modification process according to an embodiment of the invention,is shown. For illustrative purposes, FIG. 2F3 is described withreference to FIG. 2F1. However, the operations of FIG. 2F3 areapplicable to other embodiments, such as the example embodiment of FIG.2F2.

[0241] In an embodiment, control module 142 performs the steps ofroutine 206P.

[0242] In step 206Q, client 108 accesses an object pointer 206L in adocument (object) table 206A. The object pointer is an element of thedocument table, which in one embodiment, is placed at the beginning ofthe content stream.

[0243] In step 206R, client 108 accesses a vtable pointer 206B foraccess to the vtable's function pointers 206G.

[0244] In step 206S, client 108 accesses an attribute pointer 206C foraccess to data in a content stream 206I.

[0245] In step 206T, client 108 uses the vtable pointer 206B to readfunction pointers 206G for access to instance methods 206H.

[0246] In step 206U, client 108 reads the content stream 206I for accessto data 206K pointed to by attribute pointer 206C.

[0247] In step 206V, client 108 determines the requirements for the data206K. In one embodiment, client 108 determines the amount of writeablememory that the data 206K will take up.

[0248] In step 206W, client 108 allocates writeable memory according tothe requirements determined in step 206V.

[0249] In step 206X, client 108 decompresses and copies the data 206Kinto writeable memory. In one embodiment, the client 108 access portionsof hardware and operating system software of device 106 to decompressand copy the decompressed data. In another embodiment, the client 108internalizes the decompression and copying step.

[0250] In step 206Y, client 108 updates attribute pointer 206C to pointto the data 206K in writeable memory.

[0251] In step 206Z, client 108 updates vtable pointer 206B to point toinstance methods 206H for non-compressed, writeable data.

[0252] For example, referring also to FIG. 2F2, a routine can allocatewriteable memory for data 206K2. It decompresses the data 206K andcopies the data 206K into writeable memory, shown as data 206K2. Themethod then changes the attribute pointer 206C to point to data 206K2.It also changes the vtable pointer 206B to point to the non-compressed,writeable instance functions vtable 206D2.

[0253] With the modification complete, the instance method 206H calls anequivalent instance method 206H2 to actually perform the required writeoperation of the data 206K2.

[0254] A feature of this embodiment is that the operations of FIGS. 2F1and 2F2 occur invisibly (transparently) to the application calling thepointers. An additional feature is that the operation is performed onceon a per object basis. Once performed, the object stays in writeablememory for the life of the document(s)/object(s).

[0255] A result of these embodiments is that object pointer 206L ispreserved. This is important as many other objects may already have areference to object 206A via object pointer 206L.

[0256] 2.3 Detailed Object Model Embodiments

[0257] In an example application of the embodiment of FIG. 2F1, everyobject in the tree has an 8 byte (two pointers) entry in the DocumentObject Table (DOT). The entry consists of a pointer to the object'sclass vtable (table of function pointers for instance methods), and apointer to the object's data. In the case of content stream formatteddocuments, the object's data pointer points into the content stream. Itis noted that the invention is not limited to this example embodiment.

[0258] Inter-object references are via Object Identifiers (OID), whichare unique 16 bit identifiers for each object in the document. Unlikepointers, OIDs support relocation and transmission between server andclient. Entries in the DOT are ordered in OID order. That is, the OID isalso the index into the DOT. Thus, an OID can quickly be translated intoan Object pointer (which is desirable at runtime) by performing arrayarithmetic (object =&dot[oid]). By using OIDs and pointers in the DOTapproach, a number of advantages are achieved: relocatability andtransmittability from the OIDs, and ease of use, and a rational runtimemodel from the Object model.

[0259] The DOT is created when the document is being loaded, as shown inFIG. 2F1 and 2F2. An example scenario is as follows: The content streamis interrogated to see how many objects are in the document. A DOT largeenough to accommodate that number of objects is created. An applicationquickly scans through the content stream, which has objects in OIDorder. For each object the application checks the type, ensures that theclass and vtable 206D for that type is created, writes the vtablepointer 206B in the DOT entry, then writes in the data pointer 206C,pointing back to the content stream data 206K. Then, the applicationskips to the next object in content stream (each entry has a lengthprefix stored in header 206J). When the application is done it has afully populated DOT, with a number of objects that are writeable. Ifmore objects are added to the document (via scripting requests), theyare dynamically added to the end of the DOT in the form of FIG. 2F2, forexample.

[0260] Like the PODS object model, the invention's Object Model, whileimplemented in C, is compatible with C++. Objects can be represented asabstract classes (pure virtual member functions), where the base classhas no data slots. On most C++ compilers, this will guarantee that theC++ vtable entry will be forced to offset zero in the class. Thebenefit: both C [i.e., ADOM setValue(object, “xxx”)] and C++ [i.e.,object->setValue(“xxx”);] bindings (APIs) to the same object areprovided.

[0261] Referring to FIG. 2H, a diagram illustrating content structureaccording to an embodiment of the invention is shown.

[0262] Document stream 208A illustrates at a high level the structure ofthe document that includes header 208B, string table 208C, and objecttable 208D. Header 208B includes the document table information, whichcan include object size, number of objects and string sizes. Stringtable 208C includes string identifiers (SIDs) 208E that are orderedbased on the SID in a manner similar to OIDs, as discussed above. Stringidentifiers 208E include lists of word identifiers 208F, which areordered word tables 208G. Each word table contains characters 208H thatare represented by a certain code 208I.

[0263] The structure embodied in stream 208A provides the compressed andordered nature described herein. Object table 208D includes the type andsize and other attribute information for each object in the document asin FIG. 2E. String objects in these objects are string identifiersreferring to 208C.

[0264] 2.4 CSS Style Sheet Technology on Mobile Devices

[0265] Style Sheets represent a mechanism for setting and holding styleattributes. HTML elements have a number of attributes that are stylisticin nature (dimensions, colors, font information, list bullet styles,etc.). Style Sheets are just a formalized scheme of setting, getting,and most importantly sharing these attributes. An advantage of StyleSheets is that they make it very easy to make global or semi globalstylistic changes to a document.

[0266] For example, if one wants all the image borders to be 4 pixelswide, one can do that easily in one place. An advantage of supportingstyles is it will make it easier for the content developer to share HTMLbetween desktop and mobile devices—without recoding the HTML.

[0267] Also, style sheets represent a useful abstraction for attributeinformation. In an embodiment, the HTML Element super class of HTML/DOMis aware of style sheets. HTML Element provides the interface to get allattribute information for each object in the document. In oneembodiment, HTML Element obtains most of this information from the stylesheet that is associated with the object. As style sheets tend to beshared by like objects, the memory hit is not substantial.

[0268] FIGS. 2I1 and 2I2 demonstrate the effect of example style sheets.

[0269] In FIGS. 2I1 and 2I2, note the borders around Product List. Thetop and left borders are lighter, while the bottom and right borders aredarker than the background—creating a stand-out 3D effect.

[0270] The tree is made up of a three element list, where each item is atitle label and an embedded list. The embedded list is hidden by settingthe top level display property to none, then shown again by setting theproperty to block.

[0271]FIG. 2J demonstrates floating images, where the text flows aroundthe image. The example of FIG. 2J may represent a page created as a HTMLsource file, compiled on the server, and loaded onto the device forviewing.

[0272] 2.5 Overview to the Architecture of the Technology

[0273] According to an embodiment, the architecture of the invention isdesigned so that a majority of the code is in the cross platform corepieces. A component that cannot be easily made cross platform isgraphics code that draws bits on the screen. According to an embodiment,an approach is to break this component out as the Render abstraction,define a strict interface between Render and the rest of the code, andthen utilize platform specific graphics subsystems capable of pluggingback into the rest of the system.

[0274] The Draw code module deals with the semantic and programmaticlevel of graphics, leaving the Render module with only theresponsibility of putting bits on the screen, such as bits in the formof strings, rectangles, border frames, etc. By keeping the abstractionlevel low, more functionality is maintained in the cross platform code,leaving the platform specific Render engine author with less code towrite and maintain.

[0275] 2.6 Classes and Relationships within the Technology

[0276] The relationship between the render modules and the rest of thesystem is defined by a render interface. In one embodiment, an exampleheader file can be implemented. Such an example header file can includesone or more of three interfaces: ARenderMgr, ADrawCtx, and ARenderFont.

[0277] In one embodiment, ARenderMgr is the render engine. In a givenexecutable based on this technology, one can have 0, 1, or N objectsthat implement an ARenderMgr interface. In order to do a layout or drawon a DOM tree, one must have an ARenderMgr instance (actually one needsa DrawCtx which is created by a RenderMgr object—see the discussionbelow). The render engine for a given platform's graphics subsystem iscreated by a factory method on the object subclass implemented by thatplatform.

[0278] In one embodiment, ARenderFont is a font in the world of thistechnology. ARenderFont basically defines a logical abstraction of thekinds of questions the core code (especially layout) needs to ask of afont, without locking down to the (very) platform specific details ofany platform's font subsystem. ARenderFont only defines font metrics,such as “in one font, how many pixels wide is this string,” but mostplatform specific render engines may sub class and add drawing behaviorto the ARenderFont class.

[0279] In one embodiment, ADrawCtx is a drawing context and includesmany rendering and drawing capabilities. ADrawCtx provides methods forgetting bits on the screen (drawstring( ), drawRectangle( ), etc), itprovides the abstraction for the logical drawing surface (the Window,Form, or Port) that drawing occurs on, and also acts as memo pad forcoordinate information during drawing.

[0280] 2.7 Example Features

[0281] Cross-platform Construction, Layout, and Rendering Technology forDOM Application Browsers or Viewers for Mobile Devices and DHTML Layoutand Cascading Style Sheets

[0282] According to an embodiment of the invention, the cross-platformconstruction, layout, and rendering technology first parses HTML andthen constructs a document object model based on HTML tags. It then laysout those objects in the tree that represent those tags in their logicalpattern relative to their parent and children including details such asan x/y location and width and height attributes. After the layout iscomplete, the invention serializes the data and transmits it to theclient in the case of the client/server browser embodiment.

[0283]FIG. 2D1 and 2D2 (described above) illustrate example diagramsshowing an embodiment of the rendering of the client and/or server.

[0284] Rendering functionality can reside on device or on the server.All of the processes can be present on the server, leaving only thedevice specific reader to complete the pixelation of the objects, or allof the processes can be present on the device including the parser.Thus, in some embodiments, the device can receive HTML and parse itappropriately.

[0285]FIG. 2K illustrates an example construction, layout, rendering andcross-platform technology architecture according to embodiments of theinvention (see also FIGS. 2D1 and 2D2).

[0286] The diagram 227 includes server 104 and device 106. As discussedabove, content 227A in the form of HTML, CSS, wireless markup language(WML), or other format enters the system.

[0287] Parser module 227B receives the content and formats it intodiscrete objects. Parser 227B assembles the objects into DOM 227F. Here,DOM 227F is simply a placeholder for the content stream as it is beingassembled. Layout module 227C reads configuration information from proxyrender module 227E. Proxy render module 227E obtains this informationfrom the device, shown here as device configuration 227D.

[0288] Once the content stream has been assembled, emitter andcompressor module 227G forwards the content stream via communicationsmedium 227H to client 108.

[0289] The client 108 receives the content stream in DOM 227L. Loader227J forwards the content stream to render module 227M for display onscreen 227N.

[0290] Additionally, client 108 can also include optional parser module227I, and optional layout module 227K. In embodiments that include thesemodules, client 108 is capable of receiving content 227A and parsing itinto a content stream. Furthermore, layout module 227K can provide theproper configuration information directly from the device on which it isoperating.

[0291] In an embodiment, the above-described processes begin with a useraccount and device specific sync to server 104, where the server 104preemptively gathers enough information to represent the requirements ofdevice 106.

[0292] If the device is capable of layout (i.e., includes a layout andrendering module 134), then the server may sync to the device only theDOM in content stream format. Layout operations are then performed onthe device for the document.

[0293] If the device does not have a layout module, or if the server isconfigured to perform the layout operations, then the server will layoutthe document and then sync the document content and layout informationto the device.

[0294] Another feature of this embodiment is that HTML is sent to theserver. There a parser communicates with the document object model thatcreates a collection of objects (including the ability to generateobjects based on invalid HTML). From these objects, a tree of objects isgenerated that includes their layout attributes such as x/y coordinatesand their width and height. This layout is based on a proxy of thedevice on the server.

[0295] Another feature is that the level of the technology that issynced or loaded to the device can be preemptively determined. Thedevice, known or unknown to the server, will sync a proxy, or map, ofthe device requirements to the server. At the server, objects arerendered to the specifications of that proxied device before the devicesyncs. This involves parsing, rendering, and laying out of documentobjects using the proxy map of the device.

[0296] For example, suppose that a future device syncs to a currentserver. The invention enables the device to inform the server of enoughinformation to represent its requirements. In other words, the deviceprovides enough information to enable the server to create a proxy ofthe device. The server then proxy-renders the objects to the devicebased on the proxy of the device. Then, the server may send the parsedand laid out objects or the parsed only objects to the device. In thecase of raw HTML being sent to the device, the server may not need toparticipate in the parsing process or other processes performed by theclient.

[0297]FIG. 2L illustrates an example process where a future device isable to sync with a current server. The loader, layout, and renderingmodules (as described above with respect to FIG. 2K) of the clientemploy an incremental and/or on-demand approach. To view the first pageof the document, only the first few objects (those visible) are loadedfrom the content stream. Content stream layout and rendering operationsstop after the visible set of objects has been handled.

[0298] On-device pages are not necessarily created in their entirety(although they can be). They may be viewed as instantiated objects asthey are needed. The content stream is rendered based on the need forthe elements on a page. Compressed (in content stream format) objectsare instantiated based on deltas against a default set of attributes(such as found in HTML) coded into the client application.

[0299] For example, if a document sent to the device needs to be viewed,it is quickly rendered as a set of objects rather than as a rebuilt pageof HTML.

[0300] In addition, if the page needs to change, the relevant objectsare incrementally decompressed from the content stream as describedabove with respect to FIGS. 2F1 and 2F2. Thus, the decompressed versionsof only the required objects are created. When a value in an attributeis changed by a user (for example, the name of a button is lengthened ora paragraph of text is added to the page), only the objects that must bechanged are decompressed.

[0301] For each instance of these objects, there is a table of objectsproviding an efficient way of making a byte stream into a data model.The tables are heuristic tables for matching calls to data. The objectsviewed are seen through the laid out objects. When the objects arechanged, a duplicate is created or morphed from the original object orset of objects and thus expanded based on a set of deltas. The result isa fully rendered copy of the object that is now writeable. A key to thisfunctionality is how small the viewable objects are (as they need to beon mobile devices) until they need to be writeable. They becomewriteable when they are uncompressed or inflated to a fully renderedversion.

[0302] The document object table that enables the content stream to berendered by the invention is variable and customizable. The table maymap to a function that calls data as easily as it maps to tables of dataas easily as it maps to strings of code.

[0303] Another feature is that of on-device HTML authoring. RenderedHTML and resources can be redrawn and the HTML can be sent back in acontent stream via a sync for storage in a database or posting on anetwork, intranet, or Internet.

[0304] Another feature is that the proxy-rendered nature of theinvention enables a sync process to “take-over” a device. The result maybe a single function device with a browser or application lock that canonly be reset by another sync to the server, based on new serverpreferences. This means the client in conjunction with the objectrenderer and via a sync or other “install” mechanism, can “take over” adevice for a use as a single function/single application device.

[0305] 3.0 Server-Side Preparation of Data, HTML, and Other NetworkResources and Objects for Ease-of-Use on Mobile Devices

[0306] 3.1 Server Cache Operations

[0307] As previously stated, in embodiments the invention uses serverlogic to optimize content for delivery on mobile devices. Server 104also stores optimized content in a cache. The optimized content is basedon the type of mobile device that requested the content. Thus, theinvention stores device specific versions of content requested by mobiledevices. For example, suppose a first Palm device requests document Afrom provider 128A. Provider 128A controls page caching using relativeor absolute date-time stamps. Server 104 may optionally override thepage caching from Provider 128A. Document A is retrieved from provider128A and optimized by web synchronization module 124 for use on thefirst Palm device. The optimized content is then cached for the firstPalm device. Next a Windows CE device requests document A from provider128A. Document A is retrieved from provider 128A, optimized for use bythe Windows CE device, and cached for the Windows CE device. If,sometime later, a second Palm device with identical or similarcharacteristics (depending on the implementation) as the first Palmdevice requests document A from provider 128A, document A, specific tothe first Palm device, is immediately retrieved from the cache. The websynchronization module 124 does not have to retrieve document A fromprovider 128A for the second Palm device. As the number of usersincreases, the cache hit ratio increases, resulting in fewer fetchesfrom providers 128. As the need for web synchronization module 124 toretrieve an object from provider 128 decreases, server bandwidthrequirements also decrease.

[0308]FIG. 3A is a flow diagram representing an exemplary server cacheoperation of transformed content. The process begins with step 302. Instep 302, a data object request is made by a mobile device. The mobiledevice may be, but is not limited to, any mobile device listed in Table2. The process proceeds to step 304.

[0309] In step 304, web synchronization module 124 checks to see if thedata object specific or applicable to the requesting mobile device isfound in the cache associated with the server. If the data objectspecific or applicable to the requesting mobile device is found in thecache and is still valid, the process proceeds to step 306.

[0310] In step 306, web synchronization module 124 retrieves theoptimized data object from cache. The process then proceeds to step 314.

[0311] Returning to step 304, if the data object specific or applicableto the requesting mobile device is not found in the cache or is nolonger valid, the process proceeds to step 308.

[0312] In step 308, web synchronization module 124 retrieves the dataobject from provider 128. The retrieved data object may include adate-time stamp and/or other information indicating when the data objectwill expire. The process then proceeds to step 310.

[0313] In step 310, web synchronization module 124 transforms the dataobject to a form suitable for use and/or display on the requestingmobile device. For example, an address book entry will differ for Palmand Windows CE devices. The process then proceeds to step 312.

[0314] In step 312, the transformed data object is stored in the cachewith device specific information, along with information on how long thedata object can remain in the cache (such information may include thedate-time stamp information of step 308). Note that the transformed dataobject is only stored in the cache if information retrieved fromprovider 128A indicates that the data object is cacheable or if server104 is set to override the information from provider 128A. The processthen proceeds to step 314.

[0315] In step 314, the transformed data object is sent to therequesting mobile device.

[0316] 3.1.1 Special Case of Optimization for Mobile Devices:

[0317] Negative Caching of Compressed Error Messages In one embodiment,negative caching is implemented. Negative caching involves cachingerrors that result when web synchronization module 124 is unable toretrieve the requested data object from provider 128. This eliminatesthe need to subsequently access the provider 128. For example, ifprovider 128 is down, negative caching may lessen the number of negativehits that would otherwise result if attempts were made to retrieve dataobjects from provider 128. When web synchronization module 124subsequently checks the cache for the irretrievable requested data, itwill see the cached error message and will make no attempt to retrievethe data from provider 128.

[0318] For example, suppose device A requests a page. The websynchronization module 124 requests the page from provider 128. However,when web synchronization module 124 requests the page from provider 128,an error is returned indicating that the page is unavailable. Websynchronization module 124 caches the error, setting configurableexpiration information. Later, another device (device B) withcharacteristics similar to device A requests the same page. Websynchronization module 124 will see the cached error (assuming that thiscached error is still valid) indicating that the page is irretrievable.Therefore, web synchronization module 124 will not have to make anattempt to retrieve the page from provider 128.

[0319]FIG. 3B is an exemplary flow diagram representing negative cachingof error messages. The process begins with step 322. In step 322, a dataobject request is made by a mobile device. The process proceeds to step324.

[0320] In step 324, web synchronization module 124 checks to see if thedata object specific or applicable to the requesting mobile device isfound in the cache associated with the server. If the data objectspecific or applicable to the requesting mobile device is found in thecache, the process proceeds to step 326.

[0321] In step 326, web synchronization module 124 retrieves theoptimized data object from the cache. The process then proceeds to step336.

[0322] Returning to step 324, if the data object specific or applicableto the requesting mobile device is not found in the cache, the processproceeds to step 328.

[0323] In step 328, web synchronization module 124 attempts to retrievethe data object from provider 128. The retrieved data object may includea date-time stamp and/or other information indicating when the dataobject will expire. The process then proceeds to decision step 330.

[0324] In decision step 330, it is determined whether an errorindicating that the requested data object was irretrievable occurred asa result of step 328. If an error message occurred, the process proceedsto step 333. If no error message occurred, the process proceeds to step332.

[0325] In step 332, web synchronization module 124 transforms theretrieved data object to a form suitable for use and/or display on therequesting mobile device. The process then proceeds to step 334.

[0326] Returning to decision step 330, if an error message occurred, websynchronization module 124, in step 333, transforms the error message toa form suitable for display on the requesting mobile device. The processthen proceeds to step 334.

[0327] In step 334, the transformed data object or the error message isstored in the cache with device specific information, which may includean indication of how long such information may be cached (as explainedabove). Note that the transformed data object or error message is onlystored in the cache if information retrieved from provider 128Aindicates that the data object is cacheable or if server 104 is set tooverride the information from provider 128A. Server 104 may providespecial overrides for negative caching of error messages. The processthen proceeds to step 336.

[0328] In step 336, the transformed data object or the error message issent to the mobile device.

[0329] 3.1.2 Stochastic Cache Expiration Algorithm

[0330] Normally, when a large group of users sync daily, at least someof the users are syncing the same version of a set of pages all of whichwill expire at the same time. For example, if server 104 has a millionusers with a page on each user's device that expires at 12 midnight onSep. 9, 2000, every single device connected to server 104 at that moment(which in a wireless world may be all of the mobile devices) willrequest server 104 to provide those pages. An example diagramillustrating all hits on a server occurring at the same time is shown inFIG. 3C for the above example. As seen in FIG. 3C, the diagram shows allof the hits on server 104 occurring at once, that is, 12 midnight. Thiscauses slow serving of new pages to all devices and puts excess stresson server 104 and provider 128.

[0331] To prevent the above scenario from occurring, an embodiment ofthe invention randomizes the expiration of the objects. This results infast serving of new objects to all devices and puts less stress onserver 104 and provider 128.

[0332] Server 104 sets a freshness lifetime for each object (or, in someembodiments, for groups of objects) stored in the cache. If the age ofan object stored in the cache is within some % of the freshness lifetime(e.g. if it is about to expire), otherwise known as Server FL or serverfreshness lifetime, then server 104 will vary the expiration of thecached object to determine whether the cached object should expire. The% of the freshness lifetime is usually set at the startup of server 104using server preferences set by an administrator. Alternatively, the %of the freshness lifetime may be configurable.

[0333] Server 104 uses freshness lifetime for determining whether or notto modify the expiration of the cached object. Server 104 determineswhether the cached object is close to expiring and then in an embodimentit uses a stochastic function to determine whether or not to expire thecached objects. The stochastic function is used if the current age ofthe cached object is within some percentage of the freshness lifetime.

[0334]FIG. 3D is an example flow diagram representing a method forrandomizing the expiration of objects set to expire at the same timeaccording to an embodiment of the invention. The process is performedfor any given object in the cache (called the cached object). Theprocess begins with step 342. In step 342, server 104 determines thecached object's freshness lifetime. The cached object's freshnesslifetime (FL) is the time of expiration (Texp) of the cached objectminus the time in which the object was placed in the cache (Tin-cache).In embodiments, the time of expiration is given when the object isretrieved from the provider 128. If the time of expiration is not given,server 104 may set a time of expiration for the object, or this may beconfigurable. The cached object's freshness lifetime is:

Object's FL=Texp−Tin-cache  (1)

[0335] The process then proceeds to step 344.

[0336] In step 344, server 104 determines the cached object's age. Thecached object's age is the total time that the object has been stored inthe cache. The cached object's age is

Object's Age=Tnow−Tin-cache  (2)

[0337] where Tnow is the current time. The process then proceeds to step346.

[0338] In step 346, server 104 determines the % of the object'sfreshness lifetime. The % of the object's freshness lifetime is theobject's age divided by the object's freshness lifetime. The % of theobject's freshness lifetime is:

% of the Object's FL=Object's Age/Object's FL  (3)

[0339] The process then proceeds to decision step 348.

[0340] In decision step 348, it is determined whether the % of theObject's FL<% of the server FL. As previously stated, the % of theserver FL is the % of the freshness lifetime set at the startup ofserver 104 using server preferences set by an administrator.Alternatively, the % of the server FL may be configurable. If it isdetermined that the % of the Object's FL is less than the % of theServer FL, then the process proceeds to step 350.

[0341] In step 350, the object is determined not to have expired. Theprocess then proceeds to step 352.

[0342] In step 352, the object is retrieved from the cache and processedin an implementation or application dependent manner.

[0343] Returning to decision step 348, if it is determined that the % ofthe Object's FL is greater than or equal to the % of the Server FL, thenthe process proceeds to step 354.

[0344] In step 354, in an embodiment, a random number is generated usinga random number generator. In one embodiment, the random numbergenerator may be normally distributed. In another embodiment, the randomnumber generator may be uniformly distributed. One skilled in therelevant arts would know that other distributions may be used withoutdeparting from the scope of the present invention. The process thenproceeds to decision step 356.

[0345] In decision step 356, it is determined whether the random numbergenerated in step 354 is less than the % of the Object's FL. If therandom number is greater than or equal to the % of the Object's FL, thenthe process proceeds to step 350, where the object is determined not tohave expired, and is then retrieved from the cache in step 352.

[0346] Returning to decision step 356, if it is determined that therandom number generated in step 354 is less than the % of the Object'sFL, then the process proceeds to step 358.

[0347] In step 358, it is determined that the object has expired. Theprocess then proceeds to step 360.

[0348] In step 360, server 104 attempts to retrieve the object fromprovider 128.

[0349] The following is an example of how the above method worksaccording to an embodiment of the invention. As previously stated, ifthe % of the Object's FL is within the % of the FL set by the server,the stochastic process is implemented. If, for example, an object's ageis 190 and the object's freshness lifetime is 200, the object's age is95% of the object's freshness lifetime. Suppose server 104 was set for athreshold of 90% of the freshness lifetime. When a decision is made tovary the expiration for determining whether the object is fresh orexpired, the probability that the object is expired is determined byfiguring out what percentage of the vary range (90-100%) the current ageof the object has covered. The vary range is 90-100 percent, and sincethe age of the object is 95%, 50% is the probability that the object isexpired. If the age were 92% of the freshness lifetime, the probabilitywould be 20%, if 98, 80%, etc. Similarly, if the range were 80-100, andthe age is 95%, the probability would be 75%. Then the random number isgenerated, and compared to the probability in order to determine if theobject is fresh or expired. Table 3 shows the age of the object, theobject's % of freshness lifetime, and the probability that the objectwill expire for the above example. TABLE 3 Age % of FreshnessLifetime/100 Probability of Expiring 179 .895 0% (not considered) 185.925 25% 190 .95 50% 195 .975 75% 200 1.0 100% 

[0350]FIG. 3E is a diagram showing freshness lifetime for the objectdescribed in the above example. The shaded area indicates the vary rangein which it is determined if the object is fresh or expired.

[0351] 3.2 Syncing Mobile Devices

[0352] 3.2.1 Single Account/Profile-Multiple Devices

[0353] Server 104 enables a single account/profile user to sync multipledevices and obtain device specific content on each device. FIG. 3F is anexample block diagram 362 illustrating a single account/profile havingmultiple devices. Block diagram 362 comprises a user account/profile364, a first mobile device 366, a second mobile device 368, a thirdmobile device 370, server 104, and providers 128. First mobile device366 may be a Palm device. Second mobile device 368 may be a cell phone.Third mobile device 370 may be Windows CE device. Although, FIG. 3Fshows three mobile devices associated with a single account/profile, oneskilled in the relevant art(s) would know that more devices or one lessdevice could be added or subtracted, respectively, without departingfrom the scope of the invention. User account/profile 364 is associatedwith each mobile device 366-370. Each mobile device 366-370 interactswith server 104 via a transmission medium which may be any wired orwireless medium using any communication protocol. Server 104 may alsoconnect to providers 128.

[0354] When any one of mobile devices 366-370 initially connects toserver 104, each device 366-370 will provide its device characteristicsto server 104. Server 104 will store the device characteristics indatabase module 126 and send the device characteristics to websynchronization module 124 and/or server extension module 156. Forsubsequent connections with server 104, each mobile device 366-370 willidentify itself to server 104 and server 104 will retrieve the device'scharacteristics from database module 126. In one embodiment, as long asthe user continues to sync devices 366-370 with server 104, server 104will maintain each device's information on database module 126. If anyone of devices 366-370 are not synced within some predetermined period,server 104 may optionally delete that device's information from databasemodule 126. If a user syncs devices 366-370, one right after the other,each device 366-370 will have the same content, but the content will beoptimized for each specific device 366-370.

[0355] An embodiment of the invention also provides a common link toshare and sync data objects between disparate user devices. For example,if user account/profile 364 has a personal digital assistant and a cellphone, neither the PDA nor the cell phone may have the ability tocommunicate directly with each other. Assume an address book exists onboth the cell phone and the PDA. The address book must be separatelyupdated since the two devices do not have the ability to communicatewith each other. However, by using server 104 of the present invention,the PDA and the cell phone may sync up with server 104 to provide thesame information on both devices. In this example, the address book ofboth devices may sync up with server 104 to enable the address book onboth the PDA and cell phone to contain the same information. Thus, theinvention syncs disparate user devices by providing server 104 as acommon link to share and sync data objects.

[0356] 3.2.2 Single Device—Multiple Servers

[0357] The invention also enables a single device to connect to multipleservers. FIG. 3G shows an example screen shot for enabling a user to addmultiple servers. FIG. 3H is an exemplary block diagram 363 representinga single mobile device that connects to multiple servers. Diagram 363comprises single user account/profile 364 connected to mobile device366, which, in turn, can be connected to a plurality of servers 365,367, and 369 that may be connected to any variety of providers 128, suchas the Web, a database, such as LOTUS Notes, or a network, respectively.Although FIG. 3H shows three servers 365-369, one skilled in therelevant art(s), based on the teachings contained herein, would knowthat more servers or less servers could be implemented without departingfrom the scope of the invention. When a user initiates a sync, in anembodiment, device 366 will be synced to each enabled server on device366, one at a time.

[0358]FIG. 3I is an exemplary flow diagram representing a sync processfor a device connected to multiple servers. The process begins with step374. In step 374, a user initiates a sync. The process proceeds to step376.

[0359] In step 376, a list of sync servers and accounts per server areretrieved. The process then proceeds to step 378.

[0360] In step 378, device 366 is synced to each server, one at a time.

[0361] 3.2.3 Multiple Devices—Multiple Servers

[0362] The invention also allows multiple devices for a single useraccount/profile to be connected to a plurality of servers. A multipledevice—multiple server scenario is shown in FIG. 3J. Although threemobile devices and three servers are shown in FIG. 3J, one skilled inthe art would know that more or less devices and servers could be usedwithout departing from the scope of the invention. In one embodiment,user account/profile 364 can cache a variety of device characteristics366, 368, and 370 used to access a variety of servers 365, 367, and 369.In one embodiment, the user can store the device profiles on a desktopand store the multi-server connections on devices 366, 368, and 370.When the user initiates a sync for any one of devices 366, 368, and 370,a list of sync servers and accounts per server is retrieved for thedevice and the device is synced to each server in the list, one at atime. The user may then sync the next device, as described above insection 3.2.1.

[0363] 4. Executing Scripts on Mobile Devices

[0364] 4.1 Overview

[0365] According to an embodiment, the present invention transforms,loads, and executes scripts onto mobile devices. The present inventionis able to retain the interactivity of the scripts with a data object,such as a HTML document or object of other forms, from which they wereoriginally located. The present invention retains the functionality ofthe scripts on mobile devices, such as device 106. According toembodiments of the present invention, scripts can be executed on clients108 which are currently connected to a server or network. According toalternative embodiments of the present invention, scripts can execute ondevices which are not currently connected to a server or network throughany type of connection (wired, wireless, etc.).

[0366] The terms “script,” “executable script,” “applet,” and the pluralform of these terms are used interchangeably throughout this document torefer to programs that accompany or are embedded within an object (It isnoted that the invention is described, at times, in terms of HTMLdocuments for illustrative purposes, but the invention is not limited tothis examples. The invention includes operations with other types ofdata objects, such as but not limited to other mark-up language ortag-based documents.). Various HTML specifications define how scriptscan be included in objects (i.e., Web pages), so that programmers candevelop objects that can accept scripts.

[0367] Scripts can be programmed to execute immediately when the objectis loaded into a client, a client's Web browser or otherdisplay-interface program. Alternatively, scripts can also be programmedto execute in response to browser events, such as when a user clicks ona button or when the user resets a form in the object.

[0368] The terms “scripting language,” “script language,” “programminglanguages,” and the plural form of these terms are used interchangeablythroughout this document to refer to computer programming languages usedto make scripts. As one skilled in the relevant art(s) would recognize,based at least on the teachings herein, many programming languages canbe used as scripting languages, including but not limited to thefollowing programming languages: JavaScript, ECMAScript, Java, Perl,Tcl, Visual Basic, and VBScript.

[0369] 4.2 Server-Side Compilation

[0370] Many programming languages are implemented with executableprograms which transform their source file (e.g., a script) into aprogram. Many programming languages include a compiler. Some programminglanguages include an interpreter.

[0371] A compiler translates a file written in a source language into anequivalent computer program in a target language. Some compilerstranslate the file written in the source language directly to a machinelanguage, which can be directly executed by a device 106, server 104, orclient 108. Other compilers translate the file into an intermediatestage known as a virtual machine language.

[0372] An interpreter is an auxiliary program which can execute virtualmachine code. Virtual machine languages are sometimes called byte codeor P-code languages. Interpreters for these languages are sometimescalled byte code interpreters or P-code interpreters.

[0373]FIG. 4 is a block diagram illustrating script compiler modulesaccording to an embodiment of the invention. In FIG. 4, block diagram400 depicts content provider 128, server 104 and client 108. The server104 includes script compiler modules 402 a-402 n for compiling,transforming, and recompiling scripts into languages executable andcompatible with client 108 and device 106. The client 108 includesseveral language interpreter modules 404 a-404 n for interpretingscripts arriving in form of virtual machine language.

[0374] In FIG. 4, a content provider 128 sends scripts along with anHTML page to the server 104. The server 104 interprets the page'sscripts, which generate HTML and scripts as its output. This output istokenized and sent to the client 108.

[0375] The client 108 also includes several script compiler modules 406a-406 n which are capable of performing the functionality of scriptcompiler modules 402 a-402 n. Modules 406 are available in embodimentswhere the server 104 is bypassed.

[0376] The content provider 128 sends objects and scripts to the server104. According to one embodiment of the present invention, the scriptcompiler module 402 compiles the scripts to virtual machine languageaccording to the specifications of the client 108 and/or device 106. Theserver 104 sends the compiled scripts along with tokenized object to theclient 108.

[0377] In one embodiment of the present invention, the client 108requests an object from the server 104. Upon receiving the request, thescript compiler modules 402 of the server 104 compile each scriptassociated with the object, according to the script language for whichthey are implemented. In embodiments of the present invention, theserver 104 can contain a separate script compiler module for eachscripting language which it supports.

[0378] In one embodiment, as shown in FIG. 4, the script compilermodules 402 are managed by the server extension module 156. Eachcompiled script is sent to the requesting client where it can be storedand executed. In alternative embodiments of the invention, theclient-side script compiler modules 406 can compile scripts directly tothe machine language of a target client 108. In other embodiments of theinvention, the client-side compiler modules 406 can compile scripts to avirtual machine language, which is interpreted by the languageinterpreter modules 404 of the client 108.

[0379] In one embodiment of the present invention, clients 108 anddevices 106 can support several different virtual machine languages. Asingle client 108 can contain several language interpreter modules 404.The language interpreter modules 404 of client 108 can be managed by theclient extension interface 138, as shown in FIG. 4.

[0380] In further embodiments, the server 104 can communicate with anumber of clients 108 and devices 106 which support differing sets ofvirtual machine languages.

[0381] In one embodiment of the present invention, when the client 108syncs with the server 104, it sends to the server 104 an encoded list ofthe virtual machine languages which it supports. In one embodiment ofthe present invention, if the server 104 is not able to compile a scriptin a particular script language to any of the languages which the client108 supports, then it will not send any virtual machine code for thescript to the client 108 and the client 108 can effectively ignore thescript.

[0382] 4.3 Storing Interpreter Data Structures

[0383] As described herein, the language interpreter modules 404 on theclient 108 interpret virtual machine code sent from the server 104. Inone embodiment, the client operating system (e.g., Palm OS, Windows CE,Pocket PC) provides applications with two different types of memoryarchitecture: one type which is fast to write to; and another type whichis much slower to write to (It is noted that these speeds are relativeand the actual speeds are implementation and application dependant.).

[0384] For example, but without limitation, on Palm devices, Palm OSprovides applications with dynamic memory, which is a read-writerandom-access memory (RAM) which can be read or written in a singlemachine instruction. It also provides a storage memory, which is RAMwhich can be read with a single machine instruction, but which can bewritten only through a call to the operating system, which can take tensor hundreds of machine instructions to execute.

[0385] Here, the generic terms fast-write memory and slow-write memoryare used. On Palm OS, dynamic memory is fast-write memory and storagememory is slow-write memory. In embodiments, language interpretermodules 404 store data structures which are frequently updated infast-write memory, and store other data structures in slow-write memory.

[0386] According to embodiments of the present invention, certainvirtual machine languages can contain instructions which manipulateobjects. Each object has a number of properties, each of which has aname and a value. For example, the JavaScript language includes objectswhich have a name and a value. In embodiments using these or similarproperties, language interpreter modules 404 store the name of eachobject property in slow-write memory. Modules 404 also store the valueof each object property in fast-write memory.

[0387] This means that the language interpreter modules 404 can updatethe value of an existing object property by writing only to fast-writememory. In one embodiment, adding a new property to an object requireswriting to slow-write memory. FIG. 5 is a block diagram illustrating alanguage interpreter module according to an embodiment of the invention.In FIG. 5, a diagram depicts how a language interpreter module 404 mightrepresent a particular object O 502. Object O 502 has five properties,whose names 504 are “x,” “y,” “abc,” “foo,” and “xyz,” respectively. Theproperties' values 510 are “3,” “7,” “home,” “start,” and “false,”respectively.

[0388] As one skilled in the relevant art(s) would recognize, based atleast on the teachings described herein, object O 502 can have more orless than five properties (i.e., more than or less than five namesand/or values). More specifically, one skilled in the relevant art(s),based at least on the teachings described herein (e.g., with respect tothe discussion of FIGS. 5 and 6), would be able to construct object withany number of properties.

[0389] In one embodiment of the present invention, the base datastructure representing the object O 502 is stored in slow-write memoryand has two fields names 504 and values 510. The names 504 are used aspointers to an array in slow-write memory which holds pointers to eachproperty name. The values 510 are pointers to an array in fast-writememory which holds each property value.

[0390] 4.4 Using Object Delegation to Share Global Variables AcrossPages

[0391] In one embodiment of the present invention, virtual machinelanguages can support global variables, which are values that arereferenced by name anywhere within any script.

[0392] Delegation can be implemented in a number of ways. According to amethod used in embodiments of the present invention, encapsulatedobjects are linked to other objects, so that they inherit properties viaa parent or root object. Delegation introduces dynamic sharing ofbehavior between objects by adding the idea of a prototype or superobject to every object. This in turn means that one can have a prototypeor root object to begin process and pass along properties to all otherlinked objects.

[0393]FIG. 6 is a block diagram illustrating the operations of delegatedlanguage interpreter modules according to an embodiment of the presentinvention. In FIG. 6, diagram 600 illustrates the operations of languageinterpreter modules with delegation using represented global variablesas the client 108 moves from one object to the next. There are twopermanent global variables Math 608 and Date 610. These are stored asproperties of the prototype object P 606.

[0394] On the first page represented by object G 602, the globalvariable document 612 points to an object representing the HTML document618 viewed on the client 108. A script constructs two global variables x616 and y 614 with values 5 and 7, respectively. The global variablesdocument 612, x 616 and y 614 are stored as properties of a globalobject G 602 whose prototype object is object P 606. These variables areaccessible to scripts only while the client 108 remains on the firstpage represented by object G 602. When the client 108 moves to a newHTML document, it constructs a new global object H 604 and gives it itsown property document 614′ pointing to the new page's document object620. A script on the second page constructs two global variables x 616′and y 614′ with values 4 and abc, respectively. These global variablesare stored as properties of object H 604.

[0395] According to embodiments of the present invention, the values ofcertain global variables can depend on the Web page currently beingviewed. For example, in some embodiments, a global variable document 612contains an object representing the current HTML document, such asdocument object 618, which is different for each Web page view on client108. In an alternative embodiment, scripts can define new globalvariables which should be accessible to other scripts on the same HTMLdocument, but which should not be accessible to scripts running on otherHTML documents.

[0396] In further embodiments, global values are made permanent. Theyhave values which are the same for all HTML documents. For example, inembodiments which support the JavaScript language, there is a globalvariable Math which holds an object containing various mathematicalutility functions, such as Math.sin and Math.cos. In this embodiment,all scripts on all documents can access the Math object.

[0397] The embodiments described above illustrate the use of virtualmachine languages with instructions which manipulate objects withproperties. In a language with delegation, each object can contain apointer to a prototype object. In one embodiment, whenever the languageinterpreter module 404 looks for a property of an object O 502, it firstlooks for the property in the object O itself, then in O's prototypeobject, then in that object's prototype object, and so on until iteither finds the property or reaches an object which has no prototypeobject.

[0398] In one example, the Self language is used because it supportsdelegation. In another example, JavaScript is used because it alsosupports delegation. As one skilled in the relevant art(s) wouldrecognize, based at least on the teachings described herein, otherlanguages can be used, so long as they support the features ofdelegation.

[0399] In embodiments of the present invention, where the scriptlanguage is the JavaScript language, global variables are actuallyproperties of a global object. In one embodiment, if a virtual machinelanguage supports delegation, then the global object G 602 has aprototype object P 606. The object G 602 contains global variables whosevalues depend on the HTML document currently being viewed.

[0400] The object P 606 contains global variables whose values are thesame for all HTML documents. When the browser moves to a HTML document,the virtual machine interpreter modules 404 construct a new globalobject H 604. Object H's prototype object is the same object P 606 whichwas used as the prototype object for the old global object G 602. Thismeans that the interpreter module 404 does not need to reconstruct theglobal values in object P 606 or add them explicitly to the new globalobject H 604. The global values in object P 606 are accessible throughobject H 604 just as they were through object G 602.

[0401] While only object 602-606 are described, it will be apparent toone skilled in the relevant art(s), based at least on the teachingsherein, that the system of the present invention can support a pluralityof objects and HTML documents. Furthermore, according to the embodimentsdescribed herein, the objects can be cascaded with additional layers ofglobal objects.

[0402] 4.5 Server-Side Interpretation

[0403] Referring to FIG. 7, according to one embodiment of the presentinvention, the server 104 can contain one or more server-side languageinterpreter modules 704 which are used for interpreting scripts. Modules704 are managed by the server extension module 156.

[0404] In an embodiment, if a device 106 requests an object containing ascript; and

[0405] the device does not support any virtual machine language to whichthe server can compile the script;

[0406] the server contains a server-side language interpreter modulewhich can interpret the script;

[0407] the script requires no user input;

[0408] the script performs output only by generating HTML;

[0409] the script requires no access to objects which are available onlywhen its HTML page is viewed in a browser;

[0410] then the server 104 interprets the script, and sends theresulting HTML to the device 106 without sending the compiled script tothe device 106. This allows even devices 106 and client 108 which haveno virtual machine interpreter modules 404 to view and interact withobjects which contain scripts.

[0411]FIG. 7 is a block diagram illustrating a server with a server-sidelanguage interpreter module according to an embodiment of the invention.

[0412] More specifically, FIG. 7 depicts a server 104 with a server-sidelanguage interpreter module 704 communicating with a client 108 that hasno language interpreter modules 404. In FIG. 7, a content provider 128sends scripts along with an HTML page to the server 104. The server-sidelanguage interpreter module 704 interprets the page's scripts, whichgenerate HTML as their output. This HTML is tokenized and sent to theclient 108 along with the HTML representing the page itself.

[0413] 4.6 Further Embodiments of Script Operations

[0414] Referring to FIG. 8, a routine for script operations according toan embodiment of the invention is shown. The process begins with step802 and proceeds to step 804. In step 804, a client 108 sends a requestfor a document to a server 104. The client 108 can be on a device 106.The process proceeds to step 806.

[0415] In step 806, the client 108 sends a list of languages that itsupports (i.e., languages that is understands and is able to compileand/or interpret) to the server 104. Although, at times, this embodimentrefers to documents, the invention operates with any objects. Theprocess proceeds to step 808.

[0416] In step 808, the client 108 receives from the server 104 thedocument that it requested along with a script related to that document.The client 108 can request more than one document, such as a series ofdocuments which constitute a Web site. Accordingly, the client 108 canreceive any number of scripts related to those requested documents. Theprocess proceeds to step 810.

[0417] In step 810, the client 108 stores the document and script thatit received in step 808. The process proceeds to step 812.

[0418] In step 812, the client 108 accesses the stored document. Theprocess proceeds to step 814.

[0419] In step 814, the client 108 executes the stored script related tothe stored document. The process proceeds to step 816.

[0420] In step 816, the client 108 updates the properties and/orperforms other functions as called on by the executed script.

[0421] While the above embodiment describes the client 108 as operatingon one document and one script, one skilled in the relevant art(s),based at least on the teachings described herein, would recognize thatthe above embodiment can operate with any number of documents andscripts.

[0422] Referring to FIG. 9, a flowchart showing a routine for executingscripts according to an embodiment of the invention is shown. Theprocess provides a detailed embodiment of the operations of step 814.The process begins in step 904. In step 904, the client 108 determinesthe language in which the script is written. The process proceeds tostep 906.

[0423] In step 906, the client 108 performs the optional step ofcompiling the script. In one embodiment, script compiler module 406acompiles the script. The process proceeds to step 908.

[0424] In step 908, the client 108 interprets or executes the script. Inone embodiment, language interpreter module 404a interprets the script.The process proceeds to step 910.

[0425] In step 910, the client 108 receives a new page specific globalobject. In one embodiment, the client 108 receives the new page specificglobal object from operations performed by the script's operation instep 814. The process proceeds to step 912.

[0426] In step 912, the client 108 forwards a new page specific globalobject to storage memory for later retrieval. The process proceeds tostep 816.

[0427] Referring to FIG. 10, a flowchart showing a routine for updatingproperties according to an embodiment of the invention is shown. Theprocess provides a detailed embodiment of the operations of step 816.The process begins in step 1004. In step 1004, the client 108 accessesproperties associated with a new page specific global object. In oneembodiment, the new page specific global object is determined in step814. The process proceeds to step 1006.

[0428] In step 1006, the client 108 updates the associated properties.The process proceeds to step 1008.

[0429] In step 1008, the client 108 stores the associate properties.

[0430] Referring to FIG. 11, a flowchart showing a routine forserver-side script operations according to an embodiment of theinvention is shown. The process begins with step 1102 and proceeds tostep 1104. In step 1104, a client 108 sends a request for a document orother object to a server 104. The client 108 can be on a device 106. Theprocess proceeds to step 1106.

[0431] In step 1106, the client 108 sends a list of languages that itsupports (i.e., languages that is understands and is able to compileand/or interpret) to the server 104. In one embodiment, the client 108can send a null list to the server 104 that indicates that the client108 does not support any languages. The process proceeds to step 1108.

[0432] In step 1108, the client 108 receives from the server 104 thedocument or other object that it requested with information representingthe related scripts. The client 108 can request more than one documentor object, such as a series of documents which constitute a Web site.Accordingly, the client 108 can receive any number of pieces ofinformation related to those requested scripts. The process proceeds tostep 1110.

[0433] In step 1110, the client 108 stores the document and informationthat it received in step 1108. The process proceeds to step 1112.

[0434] In step 1112, the client 108 accesses the stored document. Theprocess proceeds to step 1114.

[0435] In step 1114, the client 108 accessed the stored informationrelated to the represented script.

[0436] While the above embodiment describes the client 108 as operatingon one document or object, one skilled in the relevant art(s), based atleast on the teachings described herein, would recognize that the aboveembodiment can operate with any number of documents.

[0437] 5. Conclusion

[0438] While various embodiments of the present invention have beendescribed above, it should be understood that they have been presentedby way of example only, and not limitation. It will be understood bythose skilled in the art that various changes in form and details may bemade therein without departing from the spirit and scope of theinvention as defined in the appended claims. Thus, the breadth and scopeof the present invention should not be limited by any of theabove-described exemplary embodiments, but should be defined only inaccordance with the following claims and their equivalents.

What is claimed is:
 1. A method of performing script operations formobile devices, comprising the steps of: (1) sending a request for atleast one object; (2) sending a list of support languages; (3) receivingsaid at least one object; and (4) receiving at least one script relatedto said at least one object.
 2. The method of claim 1 , furthercomprising the step of: (5) storing said at least one object and said atleast script.
 3. The method of claim 1 , further comprising the stepsof: (5) accessing said at least one object; (6) executing said at leastone script related to said at least one object.
 4. The method of claim 3, wherein step (6) comprises the steps of: (a) determining said at leastone script's language; (b) interpreting said at least one script basedon said language; (c) receiving page specific global objects; and (d)forwarding said page specific global objects.
 5. The method of claim 4 ,wherein step (a) further comprises the step of: (i) compiling said atleast one script.
 6. The method of claim 1 , further comprising the stepof: (5) updating at least one property based on operation of said atleast one script.
 7. The method of claim 6 , wherein step (5) comprisesthe steps of: (a) accessing at least one property associated with pagespecific global objects; (b) updating said at least one property; and(c) storing said at least one property.
 8. The method of claim 1 ,wherein step (4) comprises the step of: receiving informationrepresenting said at least one script, wherein said information isaccessed instead of said at least one script.
 9. A system for performingscript operations for mobile devices, comprising: first means forsending a request for at least one object; second means for sending alist of support languages; first means for receiving said at least oneobject; and second means for receiving at least one script related tosaid at least one object.
 10. The system of claim 9 , furthercomprising: means for storing said at least one object and said at leastscript.
 11. The system of claim 9 , further comprising: means foraccessing said at least one object; means for executing said at leastone script related to said at least one object.
 12. The system of claim11 , wherein said means for executing comprises: means for determiningsaid at least one script's language; means for interpreting said atleast one script based on said language; third means for receiving pagespecific global objects; and means for forwarding said page specificglobal objects.
 13. The system of claim 12 , wherein said means fordetermining further comprises: means for compiling said at least onescript.
 14. The system of claim 9 , further comprising: first means forupdating at least one property based on operation of said at least onescript.
 15. The system of claim 14 , wherein said means for updatingcomprises: means for accessing at least one property associated withpage specific global objects; second means for updating said at leastone property; and means for storing said at least one property.
 16. Thesystem of claim 9 , wherein said second means for receiving comprises:second means for receiving information representing said at least onescript, wherein said information is accessed instead of said at leastone script.
 17. A computer program product comprising a computer usablemedium having computer readable program code mans embodied in saidmedium for performing script operations for mobile devices, saidcomputer readable program code means comprising: a first computerreadable program code means for causing a computer to send a request forat least one object; a second computer readable program code means forcausing a computer to send a list of support languages; a third computerreadable program code means for causing a computer to receive said atleast one object; and a fourth computer readable program code means forcausing a computer to receive at least one script related to said atleast one object.
 18. The computer program product of claim 17 , furthercomprising: a fifth computer readable program code means for causing acomputer to store said at least one object and said at least script. 19.The computer program product of claim 17 , further comprising: a fifthcomputer readable program code means for causing a computer to accesssaid at least one object; a sixth computer readable program code meansfor causing a computer to execute said at least one script related tosaid at least one object.
 20. The computer program product of claim 19 ,wherein said sixth computer readable program code means comprises: afirst computer readable program code means for causing a computer todetermine said at least one script's language; a second computerreadable program code means for causing a computer to interpret said atleast one script based on said language; a third computer readableprogram code means for causing a computer to receive page specificglobal objects; and a fourth computer readable program code means forcausing a computer to forward said page specific global objects.
 21. Thecomputer program product of claim 20 , wherein said first computerreadable program code means further comprises: a first computer readableprogram code means for causing a computer to compile said at least onescript.
 22. The computer program product of claim 17 , furthercomprising: a fifth computer readable program code means for causing acomputer to update at least one property based on operation of said atleast one script.
 23. The computer program product of claim 22 , whereinsaid fifth computer readable program code means comprises: a firstcomputer readable program code means for causing a computer to access atleast one property associated with page specific global objects; asecond computer readable program code means for causing a computer toupdate said at least one property; and a third computer readable programcode means for causing a computer to store said at least one property.24. The computer program product of claim 17 , wherein said fourthcomputer readable program code means comprises: a first computerreadable program code means for causing a computer to receiveinformation representing said at least one script, wherein saidinformation is accessed instead of said at least one script.